We recently ran in to something very similar (we were trying to do a
re-invite during early media) but ran in to a bunch of MUST's in rfc
3261 which stopped us in our tracks. If there is a reasonable way to do
this within the rfc I would love to know a good way. Is sending another
183 in early media allowed? Can we do this in the case that we have
made the call? The application this is for is a b2bua, where we want to
establish media (even early) and immediately switch both sides of the
call to talk directly to each other (typically during early media).
Mike
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Colin Whittaker
Sent: Wednesday, February 07, 2007 2:55 PM
To: Colin Whittaker
Cc: Pekka Pessi; [email protected]
Subject: Re: [Sofia-sip-devel] Problem with multiple 183s with SDP.
It appears other proxy's are using this method of redirecting RTP with
multiple 183s.
The Nortel DMS SIP uses this method when configuring call features like
remote access to call forwarding. It appears it wants to change the RTP
port number between the first dial-tone and the second. And sends a new
183 with a new SDP answer. I reported this as a problem to them, but
don't expect much back.
So I am going to look into how we can make Sofia handle this. I realize
it wont make it into 1.12.5 since features are frozen.
I am wondering if it is as easy as removing the check:
nua_session_client_response() line 730
else if (cr->cr_answer_recv) {
or adding a tag flag that skips this test would work.
It would then run the:
soa_set_remote_sdp(nh->nh_soa, NULL, sdp, len)
soa_process_answer(nh->nh_soa, NULL) < 0)
soa_activate(nh->nh_soa, NULL)
again.
It would have to reset all the ss flags like ss_answer_recv and
ss_complete.
Or, would it be better to simulate a new offer that is the duplicate of
the previous offer and allow the SOA to process it again.
I'm not sure how to do this, but it may be the better way to go to
follow the O/A model.
Any thoughts ?
Colin..
Colin Whittaker wrote:
Pekka Pessi wrote:
On 9/15/06, Colin Whittaker <[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]> wrote:
I'm not seeing any processing of the SDP when I receive multiple
183
replies to my INVITE.
Also, the 200 OK SDP is not being processes either.
Are those 183 100rel responses (iow, are they PRACKed)?
No, I have 100rel disabled.
This is a problem since my proxy is using this method to
redirect a call
to a voice mail server.
I see a
nua(0x102db820): INVITE: ignoring duplicate SDP in 183 Session
Progress
which I assume means the stack is not prepared for a new SDP
after the
first one.
Is the proxy violating the spec ?
Yes. The can be only one answer to a single offer.
The proxy could fork the request, that is, it could respond from
another logical endpoint, the change would be visible from another tag
in the To header. However, that would bring other complications, like
how to tell UAC that the previous fork should be dropped. I just
yesterday called forking brain-dead. Not to mention that the nua stack
does not dig forking after it has received a 183.
If the proxy would like to keep existing dialog, it could send UPDATE
with a new offer in it.
I will report this as a bug to the proxy vendor. The proxy is a
Metaswitch, and they use the DC-SIP/2.0 stack.
Well, I wish I could say this might get fixed, but I'm not expecting
much.
Would it be difficult to modify the stack to support this ?
You could have peek in nua_session.c where the code now logs the
message about duplicate sdp.
However, you have to decide how to interpret the SDP. This is the most
difficult part, I'm afraid. Standard is no help because O/A model
tells us to ignore those SDP. Of course, you could peek in the
User-Agent header in the response and make decision based on that.
In the past we have interpreted these extra SDP in subsequent 183 or
200 as new offers, and sent answer in PRACK or ACK.
Well, I have PRACK disabled since this proxy expects authentication for
PRACK and sofia does not currently support this.
Seems like the SDP should be part of the sip object passed in the event
regardless of the status. If the packet has it why wouldn't the sip
object have it ?
________________________________
------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
________________________________
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
