[Serusers] Bug with SER 9.0.2?
Alberto Cruz
acruz at tekbrain.com
Sun Jun 26 18:42:39 CEST 2005
This the section that you are talking about at my ser.cfg:
#---------------------------------------------
# we tear down the call before entering to loose route
#---------------------------------------------
if (method=="BYE" || method=="CANCEL") {
end_media_session();
append_hf("P-hint: finishing call\r\n");
};
#-------------------------------------------------
# subsequent messages withing a dialog should take the
# path determined by record-routing
#-------------------------------------------------
if (loose_route()) {
append_hf("P-hint: rr-enforced\r\n");
# The following lines are added due media proxy
if (has_totag() && (method=="INVITE" || method=="ACK")) {
if (client_nat_test("3") ||
search("^Route:.*;nat=yes")) {
# Mark as NAT'ed
setflag(6);
use_media_proxy();
};
};
# end media session for BYE and CANCEL is done above
# before entering the loose route. no need to call it here
route(1);
break;
};
So do you suggest I have to add and option for the BYE at the
loose_route to use_media_proxy again?
Regards
Alberto Cruz
Klaus Darilion wrote:
> Probably the BYE is processed in the loose_route block.
>
> regards,
> klaus
>
> Alberto Cruz wrote:
>
>> I already tried this sending the BYE to the CANCEL&INVITE route block
>> but I still have the same behavior.
>>
>> the "TEAR DOWN" block is ending the MEDIA SESSION and the CALL; isn't
>> it?
>>
>> Where should I apply the force_rport() command ?
>>
>> Regards
>>
>> Alberto Cruz
>>
>> Alberto Cruz wrote:
>>
>>> So should I have to give the same treatment to method=="CANCEL" as
>>> method=="BYE"?
>>> i.e.:
>>> if (client_nat_test("3")) {
>>> setflag(7);
>>> force_rport();
>>> fix_nated_contact();
>>> };
>>>
>>> Regards
>>>
>>> Alberto Cruz
>>>
>>> Klaus Darilion wrote:
>>>
>>>> Hi Alberto!
>>>>
>>>> The BYE message from the client has no 'rport' paramter in its Via:
>>>> header. Thus, ser sends the response to the IP:port in the via
>>>> header. As there is no port, ser assumes port 5060.
>>>>
>>>> You can manually add the rport paramter by using force_rport().
>>>> Then, ser will add the port from which it received the message
>>>> (61133) and will use this prot for responses.
>>>>
>>>> regards,
>>>> klaus
>>>>
>>>> Alberto Cruz wrote:
>>>>
>>>>> Does anybody know if the following behavior is a bug?
>>>>>
>>>>> UA behind NAT -> SER with MEDIAPROXY -> GATEWAY
>>>>>
>>>>> U 2005/06/25 22:50:59.020747 200.94.75.6:5060 ->
>>>>> *200.67.33.247:61133*
>>>>> SIP/2.0 183 Session Progress.
>>>>> Via: SIP/2.0/UDP
>>>>> 172.31.253.127:5060;rport=61133;received=200.67.33.247;branch=z9hG4bK-bb14d3a0.
>>>>>
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Date: Sun, 26 Jun 2005 03:51:20 GMT.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>> Server: Cisco-SIPGateway/IOS-12.x.
>>>>> CSeq: 101 INVITE.
>>>>>
>>>>> U 2005/06/25 22:51:06.346082 200.94.75.1:5060 -> 200.94.75.6:5060
>>>>> SIP/2.0 200 OK.
>>>>> Via: SIP/2.0/UDP
>>>>> 200.94.75.6;branch=z9hG4bK7176.047de506.0,SIP/2.0/UDP
>>>>> 172.31.253.127:5060;rport=61133;received=200.67.33.247;branch=z9h
>>>>> G4bK-bb14d3a0.
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Date: Sun, 26 Jun 2005 03:51:20 GMT.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>> Server: Cisco-SIPGateway/IOS-12.x.
>>>>> CSeq: 101 INVITE.
>>>>>
>>>>> U 2005/06/25 22:51:06.349202 200.94.75.6:5060 -> *200.67.33.247:61133
>>>>> *SIP/2.0 200 OK.
>>>>> Via: SIP/2.0/UDP
>>>>> 172.31.253.127:5060;rport=61133;received=200.67.33.247;branch=z9hG4bK-bb14d3a0.
>>>>>
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Date: Sun, 26 Jun 2005 03:51:20 GMT.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>> Server: Cisco-SIPGateway/IOS-12.x.
>>>>> CSeq: 101 INVITE.
>>>>>
>>>>> U 2005/06/25 22:51:06.463073 *200.67.33.247:61133* ->
>>>>> 200.94.75.6:5060
>>>>> ACK sip:018183324166 at 200.94.75.1:5060 SIP/2.0.
>>>>> Via: SIP/2.0/UDP 172.31.253.127:5060;branch=z9hG4bK-2cfda76b.
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>> CSeq: 101 ACK.
>>>>>
>>>>> U 2005/06/25 22:51:06.466144 200.94.75.6:5060 -> 200.94.75.1:5060
>>>>> ACK sip:018183324166 at 200.94.75.1:5060 SIP/2.0.
>>>>> Record-Route: <sip:200.94.75.6;ftag=7eee899c25104cbo0;lr=on>.
>>>>> Via: SIP/2.0/UDP 200.94.75.6;branch=0.
>>>>> Via: SIP/2.0/UDP
>>>>> 172.31.253.127:5060;received=200.67.33.247;branch=z9hG4bK-2cfda76b.
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>> CSeq: 101 ACK.
>>>>>
>>>>> U 2005/06/25 22:52:46.932753 *200.67.33.247:61133* ->
>>>>> 200.94.75.6:5060
>>>>> BYE sip:018183324166 at 200.94.75.1:5060 SIP/2.0.
>>>>> Via: SIP/2.0/UDP 172.31.253.127:5060;branch=z9hG4bK-fb84955e.
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>> CSeq: 102 BYE.
>>>>>
>>>>> U 2005/06/25 22:52:46.936356 200.94.75.6:5060 -> 200.94.75.1:5060
>>>>> BYE sip:018183324166 at 200.94.75.1:5060 SIP/2.0.
>>>>> Record-Route: <sip:200.94.75.6;ftag=7eee899c25104cbo0;lr=on>.
>>>>> Via: SIP/2.0/UDP 200.94.75.6;branch=z9hG4bK4176.978b7dd1.0.
>>>>> Via: SIP/2.0/UDP
>>>>> 172.31.253.127:5060;received=200.67.33.247;branch=z9hG4bK-fb84955e.
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>> CSeq: 102 BYE.
>>>>>
>>>>> U 2005/06/25 22:52:46.943252 200.94.75.1:5060 -> 200.94.75.6:5060
>>>>> SIP/2.0 200 OK.
>>>>> Via: SIP/2.0/UDP
>>>>> 200.94.75.6;branch=z9hG4bK4176.978b7dd1.0,SIP/2.0/UDP
>>>>> 172.31.253.127:5060;received=200.67.33.247;branch=z9hG4bK-fb84955
>>>>> e.
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Date: Sun, 26 Jun 2005 03:53:13 GMT.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>>
>>>>> U 2005/06/25 22:52:46.944910 200.94.75.6:5060 ->
>>>>> *200.67.33.247:5060 !!!! The UDP PORT was changed !!!!*
>>>>> SIP/2.0 200 OK.
>>>>> Via: SIP/2.0/UDP
>>>>> 172.31.253.127:5060;received=200.67.33.247;branch=z9hG4bK-fb84955e.
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Date: Sun, 26 Jun 2005 03:53:13 GMT.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>>
>>>>> *The UA retries the BYE again because it didn't receive the 200 OK
>>>>> with the right UDP PORT*
>>>>>
>>>>> U 2005/06/25 22:52:47.429710 *200.67.33.247:61133* ->
>>>>> 200.94.75.6:5060
>>>>> BYE sip:018183324166 at 200.94.75.1:5060 SIP/2.0.
>>>>> Via: SIP/2.0/UDP 172.31.253.127:5060;branch=z9hG4bK-fb84955e.
>>>>> From: 8183651723
>>>>> <sip:8183651723 at sipsrv.conecta-te.com>;tag=7eee899c25104cbo0.
>>>>> To: <sip:018183324166 at sipsrv.conecta-te.com>;tag=2EC3E224-C59.
>>>>> Call-ID: 994132b0-ecde4ec7 at 172.31.253.127.
>>>>> CSeq: 102 BYE.
>>>>>
>>>>> I'm using
>>>>> version: ser 0.9.2 (i386/linux)
>>>>> flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
>>>>> DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
>>>>> 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
>>>>> @(#) $Id: main.c,v 1.197 2004/12/03 19:09:31 andrei Exp $
>>>>> main.c compiled on 10:21:27 Jun 11 2005 with gcc 3.3
>>>>>
>>>>> and MEDIAPROXY 1.3.1
>>>>>
>>>>> I have the ser.cfg for PSTN from ONSIP.org
>>>>>
>>>>> Regards
>>>>>
>>>>> Alberto Cruz
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> serusers at lists.iptel.org
>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
More information about the sr-users
mailing list