SDP Negotiation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Benny
 
I have additional question on the scenario below. What would be the
correct answer if 2xx doesn't have SDP, after reliable 18x that has SDP.
 
regards,
 

Vladimir Hozjan

 

________________________________

From: pjsip-bounces@xxxxxxxxxxxxxxx
[mailto:pjsip-bounces at lists.pjsip.org] On Behalf Of Sasa Coh
Sent: Friday, June 13, 2008 9:11 AM
To: pjsip list
Subject: Re: SDP Negotiation



Hi!


On Thu, Jun 12, 2008 at 4:56 PM, Benny Prijono <bennylp at pjsip.org>
wrote:


	On Thu, Jun 12, 2008 at 2:22 PM, Sasa Coh <sasacoh at gmail.com>
wrote:
	> Hi,
	>
	> Thanks Benny, I got it. Well, we have no To-tag change and
unreliable
	> transport.
	> Is there any other SIP scenario/call flow (supported by pjsip)
that would
	> handle such functionality?
	> Scenario again: The client receives (after 18x) tones or
announcements from
	> media server and when other party answers (2xx) the SDP is
changed.
	>
	
	
	Since the To-tag doesn't change, probably we can try this.
Basically
	we will force the server to not change the SDP between 18x and
2xx
	response, by using reliable response. Hopefully this will make
the
	server sends the new SDP with UPDATE or re-INVITE, which we
support.
	
	You can force the server to send answer reliably either with
using TCP
	or TLS transport, or using reliable provisional response
extension
	with --use-100rel option (in pjsua).
	
	If the server still sends modified SDP in 2xx, at least we can
then
	blame it for being non-compliant. ;-)


Thanks a lot Benny. That's exactly what I need :-)
 
bye, 
sasa



	
	
	Cheers
	 Benny
	
	
	
	> thanks again,
	> sasa
	>
	> On Thu, Jun 12, 2008 at 2:52 PM, Benny Prijono
<bennylp at pjsip.org> wrote:
	>>
	>> On Thu, Jun 12, 2008 at 11:59 AM, Sasa Coh
<sasacoh at gmail.com> wrote:
	>> > Hello Benny!
	>> >
	>> > I have question regarding SDP negotiation process. We
managed to
	>> > establish
	>> > signaling connection with the other party but there was no
(correct)
	>> > voice
	>> > path established.
	>> >
	>> > Here is how it goes:
	>> >  - pjsua makes call through Call Agent: INVITE with SDP
(offer).
	>> >  - Call Agent responds with 180 Ringing with SDP (answer).
Here SDP
	>> > points
	>> > to the Media Server that provides "Ring Back" tone to the
caller.
	>> >  - When called party accepts the call, Call Agent sends 200
OK with yet
	>> > another SDP (offer/answer?) points to the called party.
	>> >  - After that there is no voice path... to be exact, voice
path is still
	>> > established to the media server providing tones but not to
the called
	>> > party
	>> > as directed in the latter SDP.
	>> >
	>> > The same situation works with other clients (X-Lite).
	>> >
	>> > Does pjsip support this kind of SDP negotiation? Should we
handle some
	>> > callback we are not aware of?
	>> >
	>>
	>> I think this is quite a complicated scenario, and which one
it is
	>> depends on whether the server changes the To tag between 18x
and 2xx
	>> response. If it does change, then this is a similar scenario
to
	>> forking with early media, which we don't handle at PJSUA-LIB
level (we
	>> do have basic forking handler at PJSIP level, but I don't
implement
	>> forking at PJSUA-LIB level due to complexities in handling
the media).
	>>
	>> If the To-tag doesn't change, then it further depends on
whether the
	>> SIP transport is reliable or not. If the transport is not
reliable, it
	>> means server is sending "provisional" SDP in 18x response and
the
	>> "final" SDP in the 2xx response which the UAC should use.
This, albeit
	>> hairy is a valid SIP scenario. But we don't seem to handle
this
	>> either. If the transport is reliable, then the SDP in 18x is
the final
	>> one and UAC must ignore the SDP in 2xx since it belongs to
the same
	>> transaction, and if this is the case, PJSIP is doing the
right thing.
	>>
	>> So there you go. :)
	>>
	>> Cheers
	>>  Benny
	>>
	>> _______________________________________________
	>> Visit our blog: http://blog.pjsip.org
	>>
	>> pjsip mailing list
	>> pjsip at lists.pjsip.org
	>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
	>
	>
	> _______________________________________________
	> Visit our blog: http://blog.pjsip.org
	>
	> pjsip mailing list
	> pjsip at lists.pjsip.org
	> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
	>
	>
	
	_______________________________________________
	Visit our blog: http://blog.pjsip.org
	
	pjsip mailing list
	pjsip at lists.pjsip.org
	http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
	


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080911/f0feea31/attachment.html 


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux