[Blink] Digest user

Adrian Georgescu ag at ag-projects.com
Fri Apr 30 10:08:37 CEST 2010


Hi Emil,

Indeed, that INVITE is valid RFC wise. But think about it more in a  
wider context. This behaviour expects the other end-points to do what  
is described (and convoluted) but in practice this does not happen  
with the majority of the SIP User Agents in the Internet world, Blink  
included in this case, that do negotiate the SDP starting with the  
first invite and not later.

While having SDP in the original INVITE will work with any User Agent  
on the planet, the opposite is not true, so this behaviour should be  
avoided because it leads inexorably to interoperability issues.

Being RFC correct does not also mean is also a clever thing to do  
unless you are a proprietary vendor that sale both the PBX and the  
phones like Cisco in this case. Most of the proprietary vendors do  
exactly this, they use the standards in their own tweaked way in order  
to sell more devices that complies with their solution and they do not  
care for generic interoperability with other implementations. Is  
actually a selling point for them to do this.

The actual technical reason is that PJSIP stack requires the presence  
of an SDP in the original Invite and I do not blame them for this  
design, It makes not sense for me to have INVITE with media  
description either.

In this case Blink will not work but it explicitly rejects the call  
with 488, which is also correct because it was designed to required  
SDP in the first INVITE.

Adrian

On Apr 30, 2010, at 9:32 AM, Emil Ivov wrote:

> Hey folks,
>
> (inline)
>
> На 30.04.10 08:47, Adrian Georgescu написа:
>>
>> On Apr 30, 2010, at 1:51 AM, Malcolm Caldwell wrote:
>>
>>> Hi Adrian,
>>>
>>> I now have the log from my work, although the packets are not the  
>>> same
>>> as I say yesterday.  (I wish I had saved them).  However, calls are
>>> not working, and this trace shows that:
>>>
>>> RECEIVED: Packet 19, +0:03:05.878643
>>> 2010-04-30 09:01:52.947054: SIP.SERVER.IP.ADDR:5060 -(SIP over  
>>> UDP)->
>>> MY.MAC.IP.ADDR:59181
>>> *INVITE sip:fcuzryxa at MY.MAC.IP.ADDR:59181 SIP/2.0
>>> *Date: Thu, 29 Apr 2010 23:31:54 GMT
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,  
>>> REFER,
>>> SUBSCRIBE, NOTIFY
>>> From:
>>> <sip:YYYY at SIP.SERVER.IP.ADDR>;tag=94d7ad56-fdc6-40a9- 
>>> bd8e-772b8995b8b6-47099214
>>> Allow-Events: presence
>>> Supported: timer,resource-priority,replaces
>>> Min-SE:  1800
>>> Remote-Party-ID:
>>> <sip:YYYY at 138.80.6.4;x-cisco-callback- 
>>> number=YYYY>;party=calling;screen=yes;privacy=off
>>> Content-Length: 0
>>> User-Agent: Cisco-CUCM7.0
>>> To: <sip:XXXX at MY.MAC.IP.ADDR>
>>> Contact: <sip:YYYY at SIP.SERVER.IP.ADDR:5060>;video;audio
>>> Expires: 180
>>> Call-ID: 63b1d680-bda116ea-b7-406508a at SIP.SERVER.IP.ADDR
>>> Via: SIP/2.0/UDP SIP.SERVER.IP.ADDR:5060;branch=z9hG4bKc721379491
>>> CSeq: 101 INVITE
>>> Send-Info: conference
>>> Max-Forwards: 70
>>> Alert-Info: <file://Bellcore-dr1/>
>>
>> There is no SDP with any type of supported media in this Invite.
>>
>> You are using Blink against a non-standard compliant corporate PBX
>> solution that works only with approved phone devices by Cisco.
>>
>> What do you want to see happening except rejecting it?
>
> It's probably worth noting that 3261 does authorize empty INVITEs. In
> such cases you simply need to send an offer in the OK, and get the
> answer in the ACK.
>
> From 3261, 13.2.1:
>
>         The initial offer MUST be in either an INVITE or, if not  
> there,
>         in the first reliable non-failure message from the UAS back to
>         the UAC.  In this specification, that is the final 2xx
>         response.
>
> and then:
>
>         If the initial offer is in the first reliable non-failure
>         message from the UAS back to UAC, the answer MUST be in the
>         acknowledgement for that message (in this specification, ACK
>         for a 2xx response).
>
> Here's the whole thing (starting at the bottom):
> http://tools.ietf.org/html/rfc3261#page-79
>
> Cheers,
> Emil
>
>
>>
>> Adrian
>>
>>
>>
>> _______________________________________________
>> Blink mailing list
>> Blink at lists.ag-projects.com
>> http://lists.ag-projects.com/mailman/listinfo/blink
>
> -- 
> Emil Ivov, Ph.D.                               67000 Strasbourg,
> Project Lead                                   France
> SIP Communicator
> emcho at sip-communicator.org                     PHONE:  
> +33.1.77.62.43.30
> http://sip-communicator.org                    FAX:    
> +33.1.77.62.47.31
>




More information about the Blink mailing list