[OpenSIPS-Users] B2B issue with UPDATE message

duane.larson at gmail.com duane.larson at gmail.com
Thu Mar 22 02:46:38 CET 2012


I am seeing the following issue

One of OpenSIPS users makes an outbound call through a SIP carrier. This  
gets sent to my OpenSIPS B2BUA which then sends it to the SIP carrier. The  
calls length makes it to 30 minutes and then it is killed.

I see that the SIP carrier at around the 30 minute mark is sending an  
UPDATE message to the client but for some reason when the OpenSIPS B2BUA  
sees this UPDATE message it doesn't think it is apart of the current  
dialog. So then the SIP carrier sends a BYE because it never got a reply  
back for the UPDATE. The OpenSIPS B2BUA has no problem recognizing the BYE  
message as being apart of the Dialog and sends this over to the OpenSIPS  
user. Am I doing something wrong?

Here is the NGREP
#
U 2012/03/21 16:52:45.756905 64.136.174.30:5060 -> 173.XXX.XXX.88:5060
UPDATE sip:173.XXX.XXX.88:5060 SIP/2.0.
Via: SIP/2.0/UDP 64.136.174.30:5060;branch=z9hG4bK2sansay124864862rdb11560.
To: <sip:9016XX6XX4 at irock.com>;tag=38c6d6bcece65cb87e503e966caf6840-231e.
From: sip:+15125XX6XX5 at 64.136.174.30:5060;tag=sansay124864862rdb11560.
Call-ID: B2B.164.2700287.
CSeq: 2 UPDATE.
Contact: <sip:+15125XX6XX5 at 64.136.174.30:5060>.
Max-Forwards: 70.
Content-Length: 0.
.



#
U 2012/03/21 16:52:45.757567 173.XXX.XXX.88:5060 -> 64.136.174.30:5060
SIP/2.0 404 Not Found.
Via: SIP/2.0/UDP 64.136.174.30:5060;branch=z9hG4bK2sansay124864862rdb11560.
To: <sip:9016XX6XX4 at irock.com>;tag=38c6d6bcece65cb87e503e966caf6840-231e.
From: sip:+15125XX6XX5 at 64.136.174.30:5060;tag=sansay124864862rdb11560.
Call-ID: B2B.164.2700287.
CSeq: 2 UPDATE.
Server: Ae SIP B2BUA.
Content-Length: 0.


#
U 2012/03/21 16:52:45.806886 64.136.174.30:5060 -> 173.XXX.XXX.88:5060
BYE sip:173.XXX.XXX.88:5060 SIP/2.0.
Via: SIP/2.0/UDP 64.136.174.30:5060;branch=z9hG4bK3sansay124864862rdb11560.
To: <sip:9016XX6XX4 at irock.com>;tag=38c6d6bcece65cb87e503e966caf6840-231e.
From: sip:+15125XX6XX5 at 64.136.174.30:5060;tag=sansay124864862rdb11560.
Call-ID: B2B.164.2700287.
CSeq: 3 BYE.
Max-Forwards: 70.
Content-Length: 0
.


#
U 2012/03/21 16:52:45.807455 173.XXX.XXX.88:5060 -> 50.XXX.XXX.156:5060
BYE sip:ykfoiarq at 216.12.249.203:15503 SIP/2.0.
Via: SIP/2.0/UDP 173.XXX.XXX.88;branch=z9hG4bK4aa2.7324a565.0.
To: "9016XX6XX4"  
<sip:9016XX6XX4 at irock.com>;tag=39f6bb581600405191bed20db9143c12.
From: <sip:915125XX6XX5 at irock.com>;tag=B2B.318.227.
CSeq: 2 BYE.
Call-ID: 9bd234749a0942fb931baec02c8e37fd.
Route:  
<sip:50.XXX.XXX.156;lr;ftag=39f6bb581600405191bed20db9143c12;did=07a.98264183>.
Content-Length: 0.
User-Agent: OpenSIPS (1.8.0-dev0-notls (x86_64/linux)).
Max-Forwards: 70.
Contact: <sip:173.XXX.XXX.88:5060>.
.


#
U 2012/03/21 16:52:45.887995 50.XXX.XXX.156:5060 -> 173.XXX.XXX.88:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 173.XXX.XXX.88;branch=z9hG4bK4aa2.7324a565.0.
Record-Route: <sip:50.XXX.XXX.156;lr;ftag=B2B.318.227>.
Call-ID: 9bd234749a0942fb931baec02c8e37fd.
From: <sip:915125XX6XX5 at irock.com>;tag=B2B.318.227.
To: "9016XX6XX4"  
<sip:9016XX6XX4 at irock.com>;tag=39f6bb581600405191bed20db9143c12.
CSeq: 2 BYE.
Server: Blink 0.2.7 (Windows).
Content-Length: 0.
.

#
U 2012/03/21 16:52:45.888223 173.XXX.XXX.88:5060 -> 64.136.174.30:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 64.136.174.30:5060;branch=z9hG4bK3sansay124864862rdb11560.
To: <sip:9016XX6XX4 at irock.com>;tag=38c6d6bcece65cb87e503e966caf6840-231e.
From: sip:+15125XX6XX5 at 64.136.174.30:5060;tag=sansay124864862rdb11560.
Call-ID: B2B.164.2700287.
CSeq: 3 BYE.
Contact: <sip:173.XXX.XXX.88:5060>.
Server: Ae SIP B2BUA.
Content-Length: 0.




Here is what I see in the syslog

Mar 21 16:52:45 B2BUA02 /usr/local/sbin/opensips[14256]:  
ERROR:b2b_entities:b2b_prescript_f: No dialog found, callid=  
[B2B.164.2700287], method=UPDATE
Mar 21 16:52:45 B2BUA02 /usr/local/sbin/opensips[14256]: Just entered  
Route: Call [UPDATE] domain [0] du [<null>] rd [173.XXX.XXX.88] td  
[irock.com] ds [<null>] Ri [173.XXX.XXX.88] rU[<null>] fU[+151

Mar 21 16:52:45 B2BUA02 /usr/local/sbin/opensips[14257]: b2b_request  
(B2B.164.2700287)
Mar 21 16:52:45 B2BUA02 /usr/local/sbin/opensips[14257]: B2B Request: Call  
[BYE] du [<null>] rd [173.XXX.XXX.88] td [irock.com] ds [<null>] Ri  
[173.XXX.XXX.88] rU[<null>] fU[+15125XX6XX5] ru[sip:173.XXX.XXX.88:5060]  
fu[sip:+15125XX6XX5 at 64.136.174.30:5060] tu[sip:9016XX26XX4 at irock.com]  
od[173.XXX.XXX.88] fd[64.136.174.30]
Mar 21 16:52:45 B2BUA02 /usr/local/sbin/opensips[14255]: b2b_reply  
(9bd234749a0942fb931baec02c8e37fd)
Mar 21 16:52:45 B2BUA02 /usr/local/sbin/opensips[14255]: B2B Reply: Call  
[BYE] domain [0] du [<null>] rd [<null>] td [irock.com] ds [<null>] Ri  
[173.XXX.XXX.88] rU[<null>] fU[915125XX6XX5] ru[<null>]  
fu[sip:915125XX6XX5 at irock.com] tu[sip:9016XX26XX4 at irock.com] od[<null>]  
fd[irock.com]


So because the logic doesn't think the UPDATE message is apart of the  
dialog it goes through my main route{} logic.

Any clues as to why this might be happening?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120322/c3fbbe52/attachment.htm>


More information about the Users mailing list