< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate-users] Is this scenario possible ?


Ok, none of the stuff in the 183 indicates that it is being sent reliably (no RSeq header). So, essentially what you are trying to do is issue a session preview in the 183, but then change it for the 200. This is not allowed (see RFC 3261 page 79, para 1), which is why there is no API to do it.

What, ultimately, are you trying to accomplish here?

Best regards,
Byron Campen

Hello,
 
As I understand from your message such scenario is impossible.
Also I think that maybe DUM shouldn't send the 183 message in this scenario because the 100rel is not in the INVITE.
 
What method in the UAS is used to send a re-invite in a dialog already established and change the SDP?
 
Below is the message's content:

INVITE sip:000@xxxxxxxxx SIP/2.0^M
Via: SIP/2.0/UDP 10.95.18.149;branch=z9hG4bK-d87543-ab7b9a242b6d8925-1--d87543-^M
Via: SIP/2.0/UDP 10.95.24.44;branch=0^M
Via: SIP/2.0/UDP 10.95.28.59:1326;branch=z9hG4bK-d87543-ab7b9a242b6d8925-1--d87543-;rport=1326^M
Max-Forwards: 15^M
Route: <sip: 10.95.18.149;lr>^M
Route: <sip:10.95.24.44;lr;pasoB2BUA>^M
Record-Route: <sip:10.95.24.44;ftag=1d456e63;lr=on>^M
Contact: <sip:777@xxxxxxxxxxx :1326>^M
To: "000"<sip:000@xxxxxxxxx>^M
From: "JuanMi"<sip:777@xxxxxxxxx>;tag=1d456e63^M
Call-ID: ODU2YTkzNDljMGFhNWJmN2I0NjU1Yjc2ZTQzN2M3Mzk.^M
CSeq: 1 INVITE^M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO^M
Content-Type: application/sdp^M
User-Agent: X-Lite release 1011s stamp 41150^M
Content-Length: 394^M
SDP Body...

SIP/2.0 183 Session Progress^M
Via: SIP/2.0/UDP 10.95.18.149;branch=z9hG4bK-d87543-ab7b9a242b6d8925-1--d87543-^M
Via: SIP/2.0/UDP 10.95.24.44;branch=0^M
Via: SIP/2.0/UDP 10.95.28.59:1326;branch=z9hG4bK-d87543-ab7b9a242b6d8925-1--d87543-;rport=1326^M
Record-Route: <sip:10.95.24.44;ftag=1d456e63;lr=on>^M
Contact: <sip:000@xxxxxxxxxxx:5070>^M
To: "000"<sip:000@xxxxxxxxx>;tag=fa176075^M
From: "JuanMi"<sip:777@xxxxxxxxx >;tag=1d456e63^M
Call-ID: ODU2YTkzNDljMGFhNWJmN2I0NjU1Yjc2ZTQzN2M3Mzk.^M
CSeq: 1 INVITE^M
Content-Type: application/sdp^M
Content-Length: 394^M
SDP Body....

Thank you very much.

 
2007/12/12, Byron Campen <bcampen@xxxxxxxxxxxx>:
You say that the UAC is not sending a PRACK, but did it put a Supported or Require: 100rel in the INVITE? From what you describe, it appears that DUM is under the impression that it is using 100rel when it sends that 183. (To confirm, check for the presence of a RSeq header in the 183) If the 100rel option is not present in the INVITE, DUM should not be sending the 183 as a reliable provisional, and there is a bug in DUM. Otherwise, there is a bug in the UAC (because it didn't PRACK). 

 
In the reliable provisional case, the SDP in the 183 is your final answer. You can't send another answer in the 200. Also, it is technically disallowed to send a new _offer_ in the 200, although there is some debate in the IETF on this point.

 
Best regards,
Byron Campen

Hello everybody,

 

This is my first message to the list, and I hope somebody can help me.
I would like to implement the following scenario using resiprocate and DUM.

 
UAC              B2B(resip)   cloud
---------------   ------------------   ----------
|INV(sdp)            

 

|---------------->        |              |

 

|183(sdp 1)          

 

|<---------------         |              |

 

|180(w/o sdp)       

 

|<---------------         |   ...        |

 

|200 (sdp2)          

 

|<---------------         |              |

 

|ACK                  

 

|---------------->        |              |

 

In this scenario, my application wishes to send a particular SDP in the message 183 (sdp1), and   eliminate it later on in the message 180.
Next, in the message 200, I would like to set a different SDP (sdp2).

 

Currently, I am trying to use the "provideAnswer(..)" function to
implement it but I am having problems with it. First, I am setting the
sdp1 into the message 183 using this function. This makes the DUM change
from the UAS_EarlyOffer to the UAS_EarlyProvidedAnswer state. But, this
function does not allow me neither remove the sdp1 (in the 180 message) nor
modify it (in the 200 message). When trying to modify it using the
provideAnswer function, DUM generates an assertion due to using
provideAnswer in state: UAS_EarlyProvidedAnswer

 

Are there any functions that can allow me to implement this scenario? If
so, which are those functions?
If it can not be done this way,   could I do something like this using a
re-invite message? If so,   which functions should I use to send it?

 

Note: The UAC doesnt send PRACK.

 

Thanks in advance,
_______________________________________________
resiprocate-users mailing list

 


Attachment: smime.p7s
Description: S/MIME cryptographic signature