< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
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....
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 toimplement it but I am having problems with it. First, I am setting thesdp1 into the message 183 using this function. This makes the DUM changefrom the UAS_EarlyOffer to the UAS_EarlyProvidedAnswer state. But, thisfunction does not allow me neither remove the sdp1 (in the 180 message) normodify it (in the 200 message). When trying to modify it using theprovideAnswer function, DUM generates an assertion due to usingprovideAnswer in state: UAS_EarlyProvidedAnswer
Are there any functions that can allow me to implement this scenario? Ifso, which are those functions?If it can not be done this way, could I do something like this using are-invite message? If so, which functions should I use to send it?
Note: The UAC doesnt send PRACK.
Thanks in advance,_______________________________________________resiprocate-users mailing listList Archive: http://resiprocate.org/archive/resiprocate-users/