Forwarding invite with replaces
52 views
Skip to first unread message
Felix
Oct 20, 2010, 5:02:18 AM10/20/10
to mobicents-public
Hi,
A B2BUA deployed on mobicents, i want to make a call with the
following process. (B and C registered in another sip server)
1. A send invite to B (A -> mobicents -> another sip server -> B)
2. After the dialog(A and B) established, B send an invite to C. (B ->
another sip server -> C)
3.After C answered the call from B, B will send a REFER msg to A (B -
> another sip server -> mobicents -> A)
4.After A received REFER from B, A will send an invite with replaces
to C (A -> mobicents -> another sip server -> C)
The problem is that when the mobicents server received invite/
replaces, it could not forward the message, but rejected it with 481
message(481 Call leg/Transaction does not exist).
Error Msg:
org.mobicents.servlet.sip.core.dispatchers.DispatcherException: Join/
Replaces Header : no match is found as per RFC 3911, Section 4 or RFC
3891, Section 3 in the request INVITE
......
at
org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher.dispatchMessage(InitialRequestDispatcher.java:
212)
at
org.mobicents.servlet.sip.core.SipApplicationDispatcherImpl.processRequest(SipApplicationDispatcherImpl.java:
671)
at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:
227)
at
gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:
193)
at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:
1297)
at
gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:
844)
at
gov.nist.javax.sip.stack.UDPMessageChannel.processMessage(UDPMessageChannel.java:
530)
at
gov.nist.javax.sip.stack.UDPMessageChannel.processIncomingDataPacket(UDPMessageChannel.java:
487)
at
gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:
295)
at java.lang.Thread.run(Thread.java:619)
So how to solve this issue? I don't want mobicents to handle invite/
replaces, just need to forward it to another sip server. any
configuration is missed?
Thanks
A B2BUA deployed on mobicents, i want to make a call with the
following process. (B and C registered in another sip server)
1. A send invite to B (A -> mobicents -> another sip server -> B)
2. After the dialog(A and B) established, B send an invite to C. (B ->
another sip server -> C)
3.After C answered the call from B, B will send a REFER msg to A (B -
> another sip server -> mobicents -> A)
4.After A received REFER from B, A will send an invite with replaces
to C (A -> mobicents -> another sip server -> C)
The problem is that when the mobicents server received invite/
replaces, it could not forward the message, but rejected it with 481
message(481 Call leg/Transaction does not exist).
Error Msg:
org.mobicents.servlet.sip.core.dispatchers.DispatcherException: Join/
Replaces Header : no match is found as per RFC 3911, Section 4 or RFC
3891, Section 3 in the request INVITE
......
at
org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher.dispatchMessage(InitialRequestDispatcher.java:
212)
at
org.mobicents.servlet.sip.core.SipApplicationDispatcherImpl.processRequest(SipApplicationDispatcherImpl.java:
671)
at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:
227)
at
gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:
193)
at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:
1297)
at
gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:
844)
at
gov.nist.javax.sip.stack.UDPMessageChannel.processMessage(UDPMessageChannel.java:
530)
at
gov.nist.javax.sip.stack.UDPMessageChannel.processIncomingDataPacket(UDPMessageChannel.java:
487)
at
gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:
295)
at java.lang.Thread.run(Thread.java:619)
So how to solve this issue? I don't want mobicents to handle invite/
replaces, just need to forward it to another sip server. any
configuration is missed?
Thanks
Jean Deruelle
Oct 20, 2010, 9:50:23 AM10/20/10
to mobicent...@googlegroups.com
Can you attach the Mobicents Server logs in DEBUG level for the whole call ?
I would like to see all the messages and check if it can be workaround by modifying the Replaces header at the UA side
Jean
Felix
Oct 21, 2010, 3:19:02 AM10/21/10
to mobicents-public
Hi, Jean
Since the log file is very big, i already sent you an email.
Thanks
On Oct 20, 9:50 pm, Jean Deruelle <jean.derue...@gmail.com> wrote:
> Can you attach the Mobicents Server logs in DEBUG level for the whole call ?
> I would like to see all the messages and check if it can be workaround by
> modifying the Replaces header at the UA side
>
> It seems to me this scenario was missed by the SIP Servlets 1.1
> specification and that it is an inherent problem to SIP that this draft is
> trying to addresshttp://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00, if that's
> > 212)
> > at
>
> > org.mobicents.servlet.sip.core.SipApplicationDispatcherImpl.processRequest(SipApplicationDispatcherImpl.java:
> > 844)
> > at
>
> > gov.nist.javax.sip.stack.UDPMessageChannel.processMessage(UDPMessageChannel.java:
> > 530)
> > at
>
> > gov.nist.javax.sip.stack.UDPMessageChannel.processIncomingDataPacket(UDPMessageChannel.java:
>
> - Show quoted text -
Since the log file is very big, i already sent you an email.
Thanks
On Oct 20, 9:50 pm, Jean Deruelle <jean.derue...@gmail.com> wrote:
> Can you attach the Mobicents Server logs in DEBUG level for the whole call ?
> I would like to see all the messages and check if it can be workaround by
> modifying the Replaces header at the UA side
>
> It seems to me this scenario was missed by the SIP Servlets 1.1
> specification and that it is an inherent problem to SIP that this draft is
> the case I think we will need to add a configuration parameter so that the
> container doesn't handle Replaces.
>
> Jean
>
> <http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00>
> container doesn't handle Replaces.
>
> Jean
>
>
>
>
> On Wed, Oct 20, 2010 at 11:02 AM, Felix <skystar99...@gmail.com> wrote:
> > Hi,
> > A B2BUA deployed on mobicents, i want to make a call with the
> > following process. (B and C registered in another sip server)
> > 1. A send invite to B (A -> mobicents -> another sip server -> B)
> > 2. After the dialog(A and B) established, B send an invite to C. (B ->
> > another sip server -> C)
> > 3.After C answered the call from B, B will send a REFER msg to A (B -
> > > another sip server -> mobicents -> A)
> > 4.After A received REFER from B, A will send an invite with replaces
> > to C (A -> mobicents -> another sip server -> C)
>
> > The problem is that when the mobicents server received invite/
> > replaces, it could not forward the message, but rejected it with 481
> > message(481 Call leg/Transaction does not exist).
>
> > Error Msg:
> > org.mobicents.servlet.sip.core.dispatchers.DispatcherException: Join/
> > Replaces Header : no match is found as per RFC 3911, Section 4 or RFC
> > 3891, Section 3 in the request INVITE
> > ......
> > at
>
> > org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher.dispatchMessage(InitialRequestDispatcher.java:
>
>
> On Wed, Oct 20, 2010 at 11:02 AM, Felix <skystar99...@gmail.com> wrote:
> > Hi,
> > A B2BUA deployed on mobicents, i want to make a call with the
> > following process. (B and C registered in another sip server)
> > 1. A send invite to B (A -> mobicents -> another sip server -> B)
> > 2. After the dialog(A and B) established, B send an invite to C. (B ->
> > another sip server -> C)
> > 3.After C answered the call from B, B will send a REFER msg to A (B -
> > > another sip server -> mobicents -> A)
> > 4.After A received REFER from B, A will send an invite with replaces
> > to C (A -> mobicents -> another sip server -> C)
>
> > The problem is that when the mobicents server received invite/
> > replaces, it could not forward the message, but rejected it with 481
> > message(481 Call leg/Transaction does not exist).
>
> > Error Msg:
> > org.mobicents.servlet.sip.core.dispatchers.DispatcherException: Join/
> > Replaces Header : no match is found as per RFC 3911, Section 4 or RFC
> > 3891, Section 3 in the request INVITE
> > ......
> > at
>
> > 212)
> > at
>
> > org.mobicents.servlet.sip.core.SipApplicationDispatcherImpl.processRequest(SipApplicationDispatcherImpl.java:
> > 671)
> > at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:
> > 227)
> > at
> > gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:
> > 193)
> > at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:
> > 1297)
> > at
>
> > gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:
> > at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:
> > 227)
> > at
> > gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:
> > 193)
> > at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:
> > 1297)
> > at
>
> > 844)
> > at
>
> > gov.nist.javax.sip.stack.UDPMessageChannel.processMessage(UDPMessageChannel.java:
> > 530)
> > at
>
> > gov.nist.javax.sip.stack.UDPMessageChannel.processIncomingDataPacket(UDPMessageChannel.java:
> > 487)
> > at
> > gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:
> > 295)
> > at java.lang.Thread.run(Thread.java:619)
>
> > So how to solve this issue? I don't want mobicents to handle invite/
> > replaces, just need to forward it to another sip server. any
> > configuration is missed?
>
> > Thanks- Hide quoted text -
> > at
> > gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:
> > 295)
> > at java.lang.Thread.run(Thread.java:619)
>
> > So how to solve this issue? I don't want mobicents to handle invite/
> > replaces, just need to forward it to another sip server. any
> > configuration is missed?
>
>
> - Show quoted text -
Jean Deruelle
Oct 21, 2010, 8:24:48 AM10/21/10
to mobicent...@googlegroups.com
I looked at the logs and indeed the server can't have any knowledge of the Replaces dialog since it is not maintained at the B2BUA application but farther downstream.
Before going for a property byassing the REFER behavior from the container, I would like to discuss different possibilities
Possibility A.
B2BUA application takes care of the REFER and sends the new INVITE with the replaces to UA2
When you receive the REFER, instead of forwarding it to the User Agent you send the reINVITE directly so that the original call leg from A is not touched, the call flow would look like this :
1. A send invite to B (A -> mobicents -> another sip server -> B)2. After the dialog(A and B) established, B send an invite to C. (B ->another sip server -> C)
Problem with this is that the SDP will not be changed at A and will break except if B2BUA on Mobicents is using a conference to connect users3.After C answered the call from B, B will send a REFER msg to A but B2BUA app on Mobicents will take care of it (B -> another sip server -> mobicents)4.After B2BUA app on Mobicents received REFER from B, it will send an invite with replaces to C (mobicents -> another sip server -> C)
Possibility B.
1. A send invite to B (A -> mobicents -> another sip server -> B)2. After the dialog(A and B) established, B send an invite to C. (B ->another sip server -> C)
3.After C answered the call from B, B will send a REFER msg to A but B2BUA app on Mobicents will modify the Refer-To Heders by replacing the Replaces in it with it's own CallId from tag and to tag and generate a REFER with a different Refer-To and Replaces (B -> another sip server -> mobicents -> A) and keep the mapping in sipapplicationsession
ReceivesREFER sip:135.27.208.69:5060 SIP/2.0From: "10001" <sip:10...@test.com>;tag=44ddd77791dadf1a22001b8775d1To: "6199" <sip:61...@test.com>;tag=09162450_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0fCall-ID: a1c71a775d2b285b...@135.27.208.69CSeq: 1 REFERVia: SIP/2.0/UDP 135.27.209.120;rport=5060;branch=z9hG4bK871BD1691246D8870936290-AP;ft=135.27.209.120~13c4;received=135.27.209.120Via: SIP/2.0/UDP 135.27.209.105:15070;branch=z9hG4bK871BD1691246D8870936290Via: SIP/2.0/TCP 135.27.209.105:15070;branch=z9hG4bK871BD1691246D8871936288Via: SIP/2.0/TCP 135.27.209.120;branch=z9hG4bK483da28891dadf1b42001b8775d1-AP;ft=31690Via: SIP/2.0/TCP 135.27.209.117;branch=z9hG4bK483da28891dadf1b42001b8775d1User-Agent: Avaya-VoicePortal/5.1.0.0.4206 AVAYA-SM-6.0.0.0.600020Contact: <sip:10...@135.27.209.117;transport=tcp>Refer-To: <sip:21...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&Replaces=cae6df8391dadf1b02001b8775d1%3Bfrom-tag%3D8ee6df8391dadf1af2001b8775d1%3Bto-tag%3D807cdfb843e4df1822b4c52994d00>P-Asserted-Identity: "10001" <sip:10...@test.com>Max-Forwards: 67Content-Length: 0
SendREFER sip:61...@135.27.211.55:23518;transport=udp SIP/2.0CSeq: 1 REFERFrom: "10001" <sip:10...@test.com>;tag=00425462_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0fTo: "6199" <sip:61...@test.com>;tag=4d127f7cCall-ID: Yjg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.Max-Forwards: 70Contact: <sip:135.27.208.69:5060>P-Asserted-Identity: "10001" <sip:10...@test.com>Refer-To: <sip:21...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&Replaces=jg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.%3Bfrom-tag%300425462_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f%3Bto-tag%34d127f7c>Content-Length: 0
This scenario B should work and it is how it should be handled I think since a B2BUA application is different than the proxy and acts like an endpoint it should really do that.4.After A received REFER from B, A will send an invite with replaces to Mobicents (A -> mobicents -> another sip server ->C) Mobicents will match this Replaces since it will know about it and call the B2BUA application, B2BUA Application will have kept the mapping and will generate a new INVITE with the Replaces it receives in 3. from C
Let me know your thoughts.
Jean
Felix
Oct 25, 2010, 1:46:23 AM10/25/10
to mobicents-public
Hi, Jean
It's really make the application complex, anyway, i will try to test
the solution B.
Can we disable checking of invite/replaces request in mobicents? I
want mobicents to consider the invite/replaces to be same with a new
invite request.
In this situation,mobicents will consider them as two separate call,
one is the first invite, another is the invite/replaces.
Thanks
> From: "10001" <sip:10...@test.com <sip%3A10...@test.com>>;tag=44ddd77791dadf1a22001b8775d1
>
> To: "6199" <sip:6...@test.com <sip%3A6...@test.com>>;tag=09162450_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> Call-ID: a1c71a775d2b285b266c9db4e18df...@135.27.208.69
> ;transport=tcp>
> Refer-To: <
> sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
> Replaces=cae6df8391dadf1b02001b8775d1%3Bfrom-tag%3D8ee6df8391dadf1af2001b8775d1%3Bto-tag%3D807cdfb843e4df1822b4c52994d00
>
> P-Asserted-Identity: "10001" <sip:10...@test.com <sip%3A10...@test.com>>
> CSeq: 1 REFER
> From: "10001" <sip:10...@test.com <sip%3A10...@test.com>>;tag=00425462_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> To: "6199" <sip:6...@test.com <sip%3A6...@test.com>>;tag=4d127f7c
> Refer-To: <
> sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
> Replaces=jg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.%3Bfrom-tag%3
> > > - Show quoted text -- Hide quoted text -
It's really make the application complex, anyway, i will try to test
the solution B.
Can we disable checking of invite/replaces request in mobicents? I
want mobicents to consider the invite/replaces to be same with a new
invite request.
In this situation,mobicents will consider them as two separate call,
one is the first invite, another is the invite/replaces.
Thanks
>
> To: "6199" <sip:6...@test.com <sip%3A6...@test.com>>;tag=09162450_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> Call-ID: a1c71a775d2b285b266c9db4e18df...@135.27.208.69
> CSeq: 1 REFER
> Via: SIP/2.0/UDP
> 135.27.209.120;rport=5060;branch=z9hG4bK871BD1691246D8870936290-AP;ft=135.27.209.120~13c4;received=135.27.209.120
> Via: SIP/2.0/UDP
> Via: SIP/2.0/UDP 135.27.209.105:15070;branch=z9hG4bK871BD1691246D8870936290
> Via: SIP/2.0/TCP 135.27.209.105:15070;branch=z9hG4bK871BD1691246D8871936288
> Via: SIP/2.0/TCP
> 135.27.209.120;branch=z9hG4bK483da28891dadf1b42001b8775d1-AP;ft=31690
> Via: SIP/2.0/TCP 135.27.209.117;branch=z9hG4bK483da28891dadf1b42001b8775d1
> User-Agent: Avaya-VoicePortal/5.1.0.0.4206 AVAYA-SM-6.0.0.0.600020
> Contact: <sip:10...@135.27.209.117 <sip%3A10...@135.27.209.117>
> Via: SIP/2.0/TCP 135.27.209.105:15070;branch=z9hG4bK871BD1691246D8871936288
> Via: SIP/2.0/TCP
> 135.27.209.120;branch=z9hG4bK483da28891dadf1b42001b8775d1-AP;ft=31690
> Via: SIP/2.0/TCP 135.27.209.117;branch=z9hG4bK483da28891dadf1b42001b8775d1
> User-Agent: Avaya-VoicePortal/5.1.0.0.4206 AVAYA-SM-6.0.0.0.600020
> ;transport=tcp>
> Refer-To: <
> sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
> Replaces=cae6df8391dadf1b02001b8775d1%3Bfrom-tag%3D8ee6df8391dadf1af2001b8775d1%3Bto-tag%3D807cdfb843e4df1822b4c52994d00
>
> P-Asserted-Identity: "10001" <sip:10...@test.com <sip%3A10...@test.com>>
> Max-Forwards: 67
> Content-Length: 0
>
> Send
> REFER sip:6...@135.27.211.55:23518;transport=udp SIP/2.0
> Content-Length: 0
>
> Send
> CSeq: 1 REFER
> From: "10001" <sip:10...@test.com <sip%3A10...@test.com>>;tag=00425462_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> To: "6199" <sip:6...@test.com <sip%3A6...@test.com>>;tag=4d127f7c
> Call-ID: Yjg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.
> Max-Forwards: 70
> Contact: <sip:135.27.208.69:5060>
> P-Asserted-Identity: "10001" <sip:10...@test.com <sip%3A10...@test.com>>
> Max-Forwards: 70
> Contact: <sip:135.27.208.69:5060>
> Refer-To: <
> sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
> Replaces=jg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.%3Bfrom-tag%3
Felix
Oct 25, 2010, 6:42:04 AM10/25/10
to mobicents-public
I already tested the solution B, but still has the same issue.
Refer-To has been replaced according to your suggestion.
Please check your email for the full logs.
Thanks
> CSeq: 1 REFER
> > > - Show quoted text -- Hide quoted text -
Refer-To has been replaced according to your suggestion.
Please check your email for the full logs.
Thanks
> From: "10001" <sip:10...@test.com <sip%3A10...@test.com>>;tag=44ddd77791dadf1a22001b8775d1
>
> To: "6199" <sip:6...@test.com <sip%3A6...@test.com>>;tag=09162450_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> Call-ID: a1c71a775d2b285b266c9db4e18df...@135.27.208.69
>
> To: "6199" <sip:6...@test.com <sip%3A6...@test.com>>;tag=09162450_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> Call-ID: a1c71a775d2b285b266c9db4e18df...@135.27.208.69
> CSeq: 1 REFER
> Via: SIP/2.0/UDP
> 135.27.209.120;rport=5060;branch=z9hG4bK871BD1691246D8870936290-AP;ft=135.27.209.120~13c4;received=135.27.209.120
> Via: SIP/2.0/UDP
> Via: SIP/2.0/UDP 135.27.209.105:15070;branch=z9hG4bK871BD1691246D8870936290
> Via: SIP/2.0/TCP 135.27.209.105:15070;branch=z9hG4bK871BD1691246D8871936288
> Via: SIP/2.0/TCP
> 135.27.209.120;branch=z9hG4bK483da28891dadf1b42001b8775d1-AP;ft=31690
> Via: SIP/2.0/TCP 135.27.209.117;branch=z9hG4bK483da28891dadf1b42001b8775d1
> User-Agent: Avaya-VoicePortal/5.1.0.0.4206 AVAYA-SM-6.0.0.0.600020
> Via: SIP/2.0/TCP 135.27.209.105:15070;branch=z9hG4bK871BD1691246D8871936288
> Via: SIP/2.0/TCP
> 135.27.209.120;branch=z9hG4bK483da28891dadf1b42001b8775d1-AP;ft=31690
> Via: SIP/2.0/TCP 135.27.209.117;branch=z9hG4bK483da28891dadf1b42001b8775d1
> User-Agent: Avaya-VoicePortal/5.1.0.0.4206 AVAYA-SM-6.0.0.0.600020
> Contact: <sip:10...@135.27.209.117 <sip%3A10...@135.27.209.117>
> ;transport=tcp>
> Refer-To: <
> sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
> Replaces=cae6df8391dadf1b02001b8775d1%3Bfrom-tag%3D8ee6df8391dadf1af2001b8775d1%3Bto-tag%3D807cdfb843e4df1822b4c52994d00
>
> P-Asserted-Identity: "10001" <sip:10...@test.com <sip%3A10...@test.com>>
> ;transport=tcp>
> Refer-To: <
> sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
> Replaces=cae6df8391dadf1b02001b8775d1%3Bfrom-tag%3D8ee6df8391dadf1af2001b8775d1%3Bto-tag%3D807cdfb843e4df1822b4c52994d00
>
> P-Asserted-Identity: "10001" <sip:10...@test.com <sip%3A10...@test.com>>
> Max-Forwards: 67
> Content-Length: 0
>
> Send
> REFER sip:6...@135.27.211.55:23518;transport=udp SIP/2.0
> Content-Length: 0
>
> Send
> CSeq: 1 REFER
> From: "10001" <sip:10...@test.com <sip%3A10...@test.com>>;tag=00425462_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> To: "6199" <sip:6...@test.com <sip%3A6...@test.com>>;tag=4d127f7c
>
> Call-ID: Yjg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.
> Max-Forwards: 70
> Contact: <sip:135.27.208.69:5060>
> Max-Forwards: 70
> Contact: <sip:135.27.208.69:5060>
> P-Asserted-Identity: "10001" <sip:10...@test.com <sip%3A10...@test.com>>
> Refer-To: <
> sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
> Replaces=jg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.%3Bfrom-tag%3
> 00425462_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f%3Bto-tag%34d127f7c>
> Refer-To: <
> sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
> Replaces=jg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.%3Bfrom-tag%3
> 00425462_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f%3Bto-tag%34d127f7c>
Eric Cheung
Oct 27, 2010, 5:55:02 AM10/27/10
to mobicent...@googlegroups.com
Hi Jean
Interested thread. It is tricky to get a chain of b2buas and REFER
working together.
In this use case, if the desire is to let the endpoints handle it and
mobicents just pass the REFER and INVITE/Replaces through, then it
seems SIP Servlet 1.1 spec should handle it. In 15.11.4, bullet 4, if
no SipSession matches the Replaces header, the request is treated as
an untargeted request. Normal application routing takes place. If the
AR selects the same b2bua, it will be in a different
SipApplicationSession. Assuming the apps let it through, the
INVITE/Replaces request will eventually reach C.
So it seems Mobicents should not rejects the INVITE/Repalces with 481?
Regards
Eric
Jean Deruelle
Oct 27, 2010, 6:00:29 AM10/27/10
to mobicent...@googlegroups.com
Hum right Eric, I guess we implemented the REFER RFC behavior and missed that bullet in the spec.
Felix can you open an Issue here http://code.google.com/p/mobicents/issues/entry?template=Mobicents%20Sip%20Servlets%20Template referencing this thread ?
Thanks in advance
Best regards
Jean
Eric Cheung
Oct 27, 2010, 6:13:03 AM10/27/10
to mobicent...@googlegroups.com
For possibility A, i.e. the b2bua app handles the REFER, then b2bua is
acting as a 3pcc controller. Part of flow IV in RFC 3725 can be used.
So to continue your call flow:
acting as a 3pcc controller. Part of flow IV in RFC 3725 can be used.
So to continue your call flow:
4) b2bua sends INVITE/Replaces to C, with no SDP
5) C sends 200 OK with SDP offer
6) b2bua sends re-INVITE with offer' to A
7) A sends 200 OK with answer'
8) b2bua sends ACK with answer to C, and ACK to A
Quite a lot of work. Perhaps a specialized app (like a REFER Handler)
can be written and re-used in different deployments. It can be
inserted in the app chain in the appropriate place.
I think whether you want a b2bua (and which one in a chain) to handle
the REFER or just pass through and let the endpoints handle it depends
on whether and which apps you want to stay in the call path.
Regards
Eric
jean.d...@gmail.com
Oct 28, 2010, 4:09:50 AM10/28/10
to mobicents-public
In the logs you sent me the INVITE that get replied with 481 response
has the From Tag and To Tag values reversed (The To Tag value should
be in the From Tag and From Tag value in the To Tag) in the Replaces
Header.
Jean
has the From Tag and To Tag values reversed (The To Tag value should
be in the From Tag and From Tag value in the To Tag) in the Replaces
Header.
Jean
Jean Deruelle
Oct 29, 2010, 6:08:00 AM10/29/10
to mobicents-public
Felix,
The fix for the part that is not compliant with the SIP Servlets 1.1 specification is available in this build http://hudson.jboss.org/hudson/view/Mobicents/job/MobicentsSipServletsRelease/
Could you retry and report back ?
Thanks in advance
Best regards
Jean
Felix
Nov 1, 2010, 4:50:09 AM11/1/10
to mobicents-public
Hi,Jean
Thank you very much.
The testing is successful. I will do more testing.
BTW, how do you plan to apply this feature on mobicents in the future?
Thanks
On Oct 29, 6:08 pm, Jean Deruelle <jean.derue...@gmail.com> wrote:
> Felix,
>
> The fix for the part that is not compliant with the SIP Servlets 1.1
> specification is available in this buildhttp://hudson.jboss.org/hudson/view/Mobicents/job/MobicentsSipServlet...
> > sip%3A10...@test.com <sip%253A10...@test.com>
> ...
>
> read more »- Hide quoted text -
Thank you very much.
The testing is successful. I will do more testing.
BTW, how do you plan to apply this feature on mobicents in the future?
Thanks
On Oct 29, 6:08 pm, Jean Deruelle <jean.derue...@gmail.com> wrote:
> Felix,
>
> The fix for the part that is not compliant with the SIP Servlets 1.1
>
> Could you retry and report back ?
> Thanks in advance
> Best regards
> Jean
>
> On Thu, Oct 28, 2010 at 10:09 AM, jean.derue...@gmail.com <
> Could you retry and report back ?
> Thanks in advance
> Best regards
> Jean
>
> > >>;tag=44ddd77791dadf1a22001b8775d1
>
> > > > To: "6199" <sip:6...@test.com <sip%3A6...@test.com> <
> > sip%3A6...@test.com <sip%253A6...@test.com>
>
> > > > To: "6199" <sip:6...@test.com <sip%3A6...@test.com> <
> > >>;tag=09162450_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> > > > Call-ID: a1c71a775d2b285b266c9db4e18df...@135.27.208.69
> > > > CSeq: 1 REFER
> > > > Via: SIP/2.0/UDP
>
> > 135.27.209.120;rport=5060;branch=z9hG4bK871BD1691246D8870936290-AP;ft=135.2
> > 7.209.120~13c4;received=135.27.209.120
> > > > Via: SIP/2.0/UDP 135.27.209.105:15070
> > ;branch=z9hG4bK871BD1691246D8870936290
> > > > Via: SIP/2.0/TCP 135.27.209.105:15070
> > ;branch=z9hG4bK871BD1691246D8871936288
> > > > Via: SIP/2.0/TCP
> > > > 135.27.209.120;branch=z9hG4bK483da28891dadf1b42001b8775d1-AP;ft=31690
> > > > Via: SIP/2.0/TCP
> > 135.27.209.117;branch=z9hG4bK483da28891dadf1b42001b8775d1
> > > > User-Agent: Avaya-VoicePortal/5.1.0.0.4206 AVAYA-SM-6.0.0.0.600020
> > > > Contact: <sip:10...@135.27.209.117 <sip%3A10...@135.27.209.117> <
> > sip%3A10...@135.27.209.117 <sip%253A10...@135.27.209.117>>
>
> > > > Call-ID: a1c71a775d2b285b266c9db4e18df...@135.27.208.69
> > > > CSeq: 1 REFER
> > > > Via: SIP/2.0/UDP
>
> > 135.27.209.120;rport=5060;branch=z9hG4bK871BD1691246D8870936290-AP;ft=135.2
> > 7.209.120~13c4;received=135.27.209.120
> > > > Via: SIP/2.0/UDP 135.27.209.105:15070
> > ;branch=z9hG4bK871BD1691246D8870936290
> > > > Via: SIP/2.0/TCP 135.27.209.105:15070
> > ;branch=z9hG4bK871BD1691246D8871936288
> > > > Via: SIP/2.0/TCP
> > > > 135.27.209.120;branch=z9hG4bK483da28891dadf1b42001b8775d1-AP;ft=31690
> > > > Via: SIP/2.0/TCP
> > 135.27.209.117;branch=z9hG4bK483da28891dadf1b42001b8775d1
> > > > User-Agent: Avaya-VoicePortal/5.1.0.0.4206 AVAYA-SM-6.0.0.0.600020
> > > > Contact: <sip:10...@135.27.209.117 <sip%3A10...@135.27.209.117> <
> > > > ;transport=tcp>
> > > > Refer-To: <
>
> > sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
>
> > Replaces=cae6df8391dadf1b02001b8775d1%3Bfrom-tag%3D8ee6df8391dadf1af2001b87
> > 75d1%3Bto-tag%3D807cdfb843e4df1822b4c52994d00
>
> > > > P-Asserted-Identity: "10001" <sip:10...@test.com<sip%3A10...@test.com><
> > sip%3A10...@test.com <sip%253A10...@test.com>>>
> > > > Refer-To: <
>
> > sip:2...@test.com?Expires=120&User-to-User=04FA08271000004CBEA7D0C80e266F7267646E69733D3130303031%3Bencoding%3Dhex&
>
> > Replaces=cae6df8391dadf1b02001b8775d1%3Bfrom-tag%3D8ee6df8391dadf1af2001b87
> > 75d1%3Bto-tag%3D807cdfb843e4df1822b4c52994d00
>
> > > > P-Asserted-Identity: "10001" <sip:10...@test.com<sip%3A10...@test.com><
> > > > Max-Forwards: 67
> > > > Content-Length: 0
>
> > > > Send
> > > > REFER sip:6...@135.27.211.55:23518;transport=udp SIP/2.0
> > > > CSeq: 1 REFER
> > > > From: "10001" <sip:10...@test.com <sip%3A10...@test.com> <
> > sip%3A10...@test.com <sip%253A10...@test.com>
> > > > Content-Length: 0
>
> > > > Send
> > > > REFER sip:6...@135.27.211.55:23518;transport=udp SIP/2.0
> > > > CSeq: 1 REFER
> > > > From: "10001" <sip:10...@test.com <sip%3A10...@test.com> <
> > >>;tag=00425462_4d8055f4_865ca020-87cc-44fc-a8ed-3614af0dcc0f
>
> > > > To: "6199" <sip:6...@test.com <sip%3A6...@test.com> <
> > sip%3A6...@test.com <sip%253A6...@test.com>>>;tag=4d127f7c
>
> > > > To: "6199" <sip:6...@test.com <sip%3A6...@test.com> <
> > > > Call-ID: Yjg0MDQwOTgzYTQ3NTdlYzBhY2VlMDZlMjViN2ZhZGE.
> > > > Max-Forwards: 70
> > > > Contact: <sip:135.27.208.69:5060>
> > > > P-Asserted-Identity: "10001" <sip:10...@test.com<sip%3A10...@test.com><
> > sip%3A10...@test.com <sip%253A10...@test.com>>>
> > > > Max-Forwards: 70
> > > > Contact: <sip:135.27.208.69:5060>
> > > > P-Asserted-Identity: "10001" <sip:10...@test.com<sip%3A10...@test.com><
>
> read more »- Hide quoted text -
Jean Deruelle
Nov 3, 2010, 5:43:33 AM11/3/10
to mobicent...@googlegroups.com
What do you mean ?
This bug fix will be part of the Mobicents Sip Servlets 1.5 release that is currently planned for release for 15th December 2010
Reply all
Reply to author
Forward
0 new messages