10 Aug
2006
10 Aug
'06
2:53 p.m.
Did you used that config, or you imported parts in your config? If you
can provide a network trace of the call, maybe we will be able to detect
the error.
Cheers,
Daniel
On 08/10/06 14:39, Pavel D. Kuzin wrote:
tryed with this config.
Reinvite not handled properly.
Can anybody provide example configs?
--
Pavel D.Kuzin
System Administrator
Nodex ISP
St. Petersburg, Russia
pk(a)nodex.ru
http://nodex.ru
----- Original Message ----- From: "Daniel-Constantin Mierla"
<daniel(a)voice-system.ro>
To: "Hakan YASTI" <hakanyasti(a)gmail.com>
Cc: <users(a)openser.org>
Sent: Thursday, August 10, 2006 12:35 AM
Subject: Re: [Users] nathelper & fax = bug ?
Hello,
start with:
http://voip-info.org/wiki/view/OpenSER+And+RTPProxy
The re-INVITEs should be handled there.
Cheers,
Daniel
On 08/08/06 09:38, Hakan YASTI wrote:
Hi,
Is there anybody who will share his config file,( or a samle
configuration ) which is working properly with rtp_proxy or
mediaproxy ? ( handle re-INVITEs properly ).
As I see, there are some people have the same problem,like me.
Thanks,
----- Original Message ----- From: "Daniel-Constantin Mierla"
<daniel(a)voice-system.ro>
To: "Dmitry Lyubimkov" <loft(a)onego.ru>
Cc: <users(a)openser.org>
Sent: Monday, August 07, 2006 11:12 PM
Subject: Re: [Users] nathelper & fax = bug ?
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Hello,
the latest openser should not care about type of media (audio or
image is same for openser). The problem is that you do not force
the rtpproxy for re-INVITE in your config file, but only for
initial INVITE of the call.
Cheers,
Daniel
On 08/05/06 10:52, Dmitry Lyubimkov wrote:
> Connection scheme:
> UA - router with NAT - OpenSER with nathelper - PSTN
> gateway (Cisco AS5350)
> (192.168.13.109) (217.107.59.194) (62.33.22.14)
> (62.33.22.11)
>
> Both incoming and outgoing calls work right. Openser uses the
> nathelper
> module for proxing of rtp stream of NAT UA.
> Here is example of SIP messages (call from PSTN through a gateway):
>
> 15:37:07.406529 IP 62.33.22.11.54581 > 62.33.22.14.5060: UDP, length
> 1121
> E..}........>!..>!...5...i.hINVITE sip:78142799233@voapp.ru:5060
> SIP/2.0
> Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone"
> From: <sip:78142764164@62.33.22.11>;tag=A515D068-227D
> To: <sip:78142799233@voapp.ru>
> Date: Fri, 04 Aug 2006 11:37:07 GMT
> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374(a)195.161.136.114
> Supported: timer,100rel
> Min-SE: 1800
> Cisco-Guid: 1688609156-585372123-2332753710-1711444852
> User-Agent: Cisco-SIPGateway/IOS-12.x
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
> SUBSCRIBE, NOTIFY, INFO
> CSeq: 101 INVITE
> Max-Forwards: 6
> Remote-Party-ID:
> <sip:78142764164@62.33.22.11>;party=calling;screen=yes;privacy=off
> Timestamp: 1154691427
> Contact: <sip:78142764164@62.33.22.11:5060>
> Expires: 180
> Allow-Events: telephone-event
> Content-Type: application/sdp
> Content-Length: 316
>
> v=0
> o=CiscoSystemsSIP-GW-UserAgent 4330 9654 IN IP4 62.33.22.11
> s=SIP Call
> c=IN IP4 62.33.22.11
> t=0 0
> m=audio 17088 RTP/AVP 3 18 8 0 4
> c=IN IP4 62.33.22.11
> a=rtpmap:3 GSM/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=yes
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:4 G723/8000
> a=fmtp:4 annexa=yes
>
> Nathelper works right and in the message sent to UA you can see
> already
> IP address of Openser (62.33.22.14) instead of the address of a
> gateway
> (62.33.22.11):
>
> 15:37:07.407463 IP 62.33.22.14.5060 > 217.107.59.194.47331: UDP,
> length
> 1256
> E.....@.@..|>!...k;.......n^INVITE sip:ngul@217.107.59.194:47331
> SIP/2.0
> Record-Route: <sip:62.33.22.14;lr;ftag=A515D068-227D>
> Via: SIP/2.0/UDP voapp.ru:5060;branch=z9hG4bK2d06.d63c8585.0
> Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone"
> From: <sip:78142764164@62.33.22.11>;tag=A515D068-227D
> To: <sip:78142799233@voapp.ru>
> Date: Fri, 04 Aug 2006 11:37:07 GMT
> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374(a)195.161.136.114
> Supported: timer,100rel
> Min-SE: 1800
> Cisco-Guid: 1688609156-585372123-2332753710-1711444852
> User-Agent: Cisco-SIPGateway/IOS-12.x
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
> SUBSCRIBE, NOTIFY, INFO
> CSeq: 101 INVITE
> Max-Forwards: 5
> Remote-Party-ID:
> <sip:78142764164@62.33.22.11>;party=calling;screen=yes;privacy=off
> Timestamp: 1154691427
> Contact: <sip:78142764164@62.33.22.11:5060>
> Expires: 180
> Allow-Events: telephone-event
> Content-Type: application/sdp
> Content-Length: 334
>
> v=0
> o=CiscoSystemsSIP-GW-UserAgent 4330 9654 IN IP4 62.33.22.11
> s=SIP Call
> c=IN IP4 62.33.22.14
> t=0 0
> m=audio 35858 RTP/AVP 3 18 8 0 4
> c=IN IP4 62.33.22.14
> a=rtpmap:3 GSM/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=yes
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:4 G723/8000
> a=fmtp:4 annexa=yes
> a=nortpproxy:yes
>
> After some talking the subscriber from PSTN tries to send a fax.
> PSTN gateway detects it and sends this message:
>
> 15:37:22.512722 IP 62.33.22.11.51655 > 62.33.22.14.5060: UDP, length
> 1276
> E..........z>!..>!..........INVITE
> sip:62.33.22.14:5060;from-tag=A515D068-227D;lr SIP/2.0
> Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone"
> From: <sip:78142764164@62.33.22.11>;tag=A515D068-227D
> To: <sip:78142799233@voapp.ru>;tag=bbaac0e818284ff5
> Date: Fri, 04 Aug 2006 11:37:22 GMT
> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374(a)195.161.136.114
> Route: <sip:ngul@217.107.59.194:47331>
> Supported: timer,100rel
> Min-SE: 1800
> Cisco-Guid: 1688609156-585372123-2332753710-1711444852
> User-Agent: Cisco-SIPGateway/IOS-12.x
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
> SUBSCRIBE, NOTIFY, INFO
> CSeq: 102 INVITE
> Max-Forwards: 6
> Remote-Party-ID:
> <sip:78142764164@62.33.22.11>;party=calling;screen=yes;privacy=off
> Timestamp: 1154691442
> Contact: <sip:78142764164@62.33.22.11:5060>
> Expires: 180
> Allow-Events: telephone-event
> Content-Type: application/sdp
> Content-Length: 393
>
> v=0
> o=CiscoSystemsSIP-GW-UserAgent 4330 9656 IN IP4 62.33.22.11
> s=SIP Call
> c=IN IP4 62.33.22.11
> t=0 0
> m=image 17088 udptl t38
> c=IN IP4 62.33.22.11
> a=T38FaxVersion:0
> a=T38MaxBitRate:14400
> a=T38FaxFillBitRemoval:0
> a=T38FaxTranscodingMMR:0
> a=T38FaxTranscodingJBIG:0
> a=T38FaxRateManagement:transferredTCF
> a=T38FaxMaxBuffer:200
> a=T38FaxMaxDatagram:72
> a=T38FaxUdpEC:t38UDPRedundancy
>
> Openser processes is and sends to UA:
>
> 15:37:22.513017 IP 62.33.22.14.5060 > 217.107.59.194.47331: UDP,
> length
> 1336
> E..T..@.@..,>!...k;......@n.INVITE sip:ngul@217.107.59.194:47331
> SIP/2.0
> Record-Route: <sip:62.33.22.14;lr;ftag=A515D068-227D>
> Via: SIP/2.0/UDP voapp.ru:5060;branch=z9hG4bKfc06.4b118272.0
> Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone"
> From: <sip:78142764164@62.33.22.11>;tag=A515D068-227D
> To: <sip:78142799233@voapp.ru>;tag=bbaac0e818284ff5
> Date: Fri, 04 Aug 2006 11:37:22 GMT
> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374(a)195.161.136.114
> Supported: timer,100rel
> Min-SE: 1800
> Cisco-Guid: 1688609156-585372123-2332753710-1711444852
> User-Agent: Cisco-SIPGateway/IOS-12.x
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
> SUBSCRIBE, NOTIFY, INFO
> CSeq: 102 INVITE
> Max-Forwards: 5
> Remote-Party-ID:
> <sip:78142764164@62.33.22.11>;party=calling;screen=yes;privacy=off
> Timestamp: 1154691442
> Contact: <sip:78142764164@62.33.22.11:5060>
> Expires: 180
> Allow-Events: telephone-event
> Content-Type: application/sdp
> Content-Length: 393
>
> v=0
> o=CiscoSystemsSIP-GW-UserAgent 4330 9656 IN IP4 62.33.22.11
> s=SIP Call
> c=IN IP4 62.33.22.11
> t=0 0
> m=image 17088 udptl t38
> c=IN IP4 62.33.22.11
> a=T38FaxVersion:0
> a=T38MaxBitRate:14400
> a=T38FaxFillBitRemoval:0
> a=T38FaxTranscodingMMR:0
> a=T38FaxTranscodingJBIG:0
> a=T38FaxRateManagement:transferredTCF
> a=T38FaxMaxBuffer:200
> a=T38FaxMaxDatagram:72
> a=T38FaxUdpEC:t38UDPRedundancy
>
> As you can see the nathelper module has not worked since the field
> c=IN
> IP4 62.33.22.11 has not changed.
> Probably it has taken place because m=image instead of m=audio as
> usual.
> As a result of transfer of a fax has not taken place.
> If to place UA outside for NAT router all works that once again
> confirms
> that bug is in the nathelper module.
> Questions:
> Why the module behaves so? What difference that to proxing (what
> byte stream and in what format)?
> How it can be bypassed?
>
> Also that the most interesting - UA refuses to accept T38 and
> suggests
> to use instead of it G.711 codec and the gateway agrees i.e. in
> result
> we have audio stream.
>
> Dmitry
>
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users