[Users] nathelper & fax = bug ?
Daniel-Constantin Mierla
daniel at voice-system.ro
Wed Aug 9 22:35:15 CEST 2006
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 at voice-system.ro>
> To: "Dmitry Lyubimkov" <loft at onego.ru>
> Cc: <users at openser.org>
> Sent: Monday, August 07, 2006 11:12 PM
> Subject: Re: [Users] nathelper & fax = bug ?
>
>
>> 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 at voapp.ru:5060
>>> SIP/2.0
>>> Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone"
>>> From: <sip:78142764164 at 62.33.22.11>;tag=A515D068-227D
>>> To: <sip:78142799233 at voapp.ru>
>>> Date: Fri, 04 Aug 2006 11:37:07 GMT
>>> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374 at 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 at 62.33.22.11>;party=calling;screen=yes;privacy=off
>>> Timestamp: 1154691427
>>> Contact: <sip:78142764164 at 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..... at .@..|>!...k;.......n^INVITE sip:ngul at 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 at 62.33.22.11>;tag=A515D068-227D
>>> To: <sip:78142799233 at voapp.ru>
>>> Date: Fri, 04 Aug 2006 11:37:07 GMT
>>> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374 at 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 at 62.33.22.11>;party=calling;screen=yes;privacy=off
>>> Timestamp: 1154691427
>>> Contact: <sip:78142764164 at 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 at 62.33.22.11>;tag=A515D068-227D
>>> To: <sip:78142799233 at voapp.ru>;tag=bbaac0e818284ff5
>>> Date: Fri, 04 Aug 2006 11:37:22 GMT
>>> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374 at 195.161.136.114
>>> Route: <sip:ngul at 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 at 62.33.22.11>;party=calling;screen=yes;privacy=off
>>> Timestamp: 1154691442
>>> Contact: <sip:78142764164 at 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.. at .@..,>!...k;...... at n.INVITE sip:ngul at 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 at 62.33.22.11>;tag=A515D068-227D
>>> To: <sip:78142799233 at voapp.ru>;tag=bbaac0e818284ff5
>>> Date: Fri, 04 Aug 2006 11:37:22 GMT
>>> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374 at 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 at 62.33.22.11>;party=calling;screen=yes;privacy=off
>>> Timestamp: 1154691442
>>> Contact: <sip:78142764164 at 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 at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
More information about the sr-users
mailing list