asterisk users - Mar 2005 - RE: Asterisk-Users Digest, Vol 8, Issue 152

I understand Asterisk is more like a B2BUA. But when this INFO request is
sent to asterisk, asterisk is supposed to bridge the request to the other
endpoint, right? In what situation, it decides to send a reply; in what
situation, it decides to bridge the request?

What is the role of gateway in SIP world, a proxy, a B2BUA or something
else?

Thank  you,

Wei

Date: Fri, 18 Mar 2005 12:51:28 -0600
From: Eric Wieling <eric@fnords.org>
Subject: Re: [Asterisk-Users] Asterisk handling of SIP info
To: Asterisk Users Mailing List - Non-Commercial Discussion
	<asterisk-users@lists.digium.com>
Message-ID: <423B2330.9090705@fnords.org>
Content-Type: text/plain; charset=us-ascii; format=flowed

Asterisk is not a SIP proxy.

Wei Su wrote:
> We encouter a situation where we need to use SIP info to convey infomation
> for one end point to another endpoint. I use asterisk to do the test and
> find asterisk does not forward the SIP info to another endpoint, but act
as
> UAS and returns a 4xx error message. I think asterisk is not right to
handle
> this SIP info message. 
>  
> In RFC 3261 Page 70 "This protocol is designed to be extended. Future
> extensions may define new methods and header fields at any time. An
element
> MUST NOT refuse to proxy a request becasue it contains a method or header
> field it does not know about". In this case, asterisk does not
understand
> this INFO message, so it acts as a UAS instead of proxy.
>  
> How to let asterisk just forward this request to the other endpoint and
> instead processing it as a UAS?
>  
> Thank you,
>  
> Wei
>  
>  
>  
>  
> Here is the log from the asterisk server:
>  
> Mar 17 12:01:31 WARNING[2804]: chan_sip.c:6134 receive_info: Unable to
parse
> INFO message 
>  
>  
> Here is the trace:
>  
>  
> Frame 96 (808 bytes on wire, 808 bytes captured)
> Session Initiation Protocol
>     Request-Line: INFO sip:6002@192.168.10.90 SIP/2.0
>         Method: INFO
>         Resent Packet: False
>     Message Header
>         Call-ID: 60b8596c-4135c-c0a81e68@192.168.10.90
>         From: Demo2<sip:6003@192.168.10.90;user=phone>;tag=221a0-a1cf
>             SIP Display info: Demo2
>             SIP from address: sip:6003@192.168.10.90
>             SIP tag: 221a0-a1cf
>         To: <sip:6002@192.168.10.90;user=phone>;tag=as6b294484
>             SIP to address: sip:6002@192.168.10.90
>             SIP tag: as6b294484
>         CSeq: 102 INFO
>         Via: SIP/2.0/UDP 192.168.10.164:5060
>         Contact: Demo2<sip:6003@192.168.10.164:5060;user=phone>
>         Max-Forwards: 70
>         Supported: timer
>         Proxy-Authorization: Digest
>
username="6003",realm="asterisk",uri="sip:6002@192.168.10.90",response="034d
> 6b15ec1b2fa91f59c55d51c0a8e7",nonce="70c7fe86"
>         Content-Type: application/media_control+xml
>         Content-Length: 195
>     Message body
>         <?xml version="1.0" encoding="utf-8" ?>\n
>          <media_control>\n
>           <vc_primitive>\n
>            <to_encoder>\n
>             <picture_fast_update>\n
>             </picture_fast_update>\n
>            </to_encoder>\n
>           </vc_primitive>\n
>          </media_control>
>  
> 
> Frame 97 (430 bytes on wire, 430 bytes captured)
> Session Initiation Protocol
>     Status-Line: SIP/2.0 415 Unsupported media type
>         Status-Code: 415
>         Resent Packet: False
>     Message Header
>         Via: SIP/2.0/UDP 192.168.10.164:5060
>         From: Demo2<sip:6003@192.168.10.90;user=phone>;tag=221a0-a1cf
>             SIP Display info: Demo2
>             SIP from address: sip:6003@192.168.10.90
>             SIP tag: 221a0-a1cf
>         To: <sip:6002@192.168.10.90;user=phone>;tag=as6b294484
>             SIP to address: sip:6002@192.168.10.90
>             SIP tag: as6b294484
>         Call-ID: 60b8596c-4135c-c0a81e68@192.168.10.90
>         CSeq: 102 INFO
>         User-Agent: Asterisk PBX
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
>         Contact: <sip:6002@192.168.10.90>
>         Content-Length: 0
> 
>

Wei Su wrote:
> I understand Asterisk is more like a B2BUA. But when this INFO request is
> sent to asterisk, asterisk is supposed to bridge the request to the other
> endpoint, right? In what situation, it decides to send a reply; in what
> situation, it decides to bridge the request?
It is not required to do anything with INFO requests at all, it can 
ignore them or reject them if it wants to.

It is possible to bridge the request to the other peer, but keep in mind 
that the other peer might not be SIP at all (IAX2, Zaptel, an 
application, H.323, etc.) Since Asterisk is acting as a PBX, it's free 
to choose what to do with them, if anything at all.

Right now Asterisk only handles one type of SIP INFO packet: the ones 
used for DTMF transmission.