[Blink] Digest user

Fri Apr 30 10:34:05 CEST 2010

Well what I believe is less relevant.

To see your problem solved you must see that:

1. Is supported in PJSIP
2. Is supported in SIP SIMPLE client SDK

PJSIP does accept patches and we do too, but I remember having a  
similar discussion long time ago that ended up in the same place. The  
chance of implementing this functionality in PJSIP is very low unless  
some external party provides a patch and maintains it.

Adrian

On Apr 30, 2010, at 10:18 AM, Malcolm Caldwell wrote:

> Adrian,
>
> I really thing you are attributing a motive to the vendor which is  
> unlikely.
>
> I would be highly surprised if the vendor had decided to do this  
> type of
> INVITE just to limit which phones work with their PBX.
>
>
>> From: Adrian Georgescu <ag at ag-projects.com>
>> Reply-To: <blink at lists.ag-projects.com>
>> Date: Fri, 30 Apr 2010 10:08:37 +0200
>> To: Emil Ivov <emcho at sip-communicator.org>
>> Cc: <blink at lists.ag-projects.com>
>> Subject: Re: [Blink] Digest user
>>
>> 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
>>
>
> _______________________________________________
> Blink
>> mailing
>> list
> Blink at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo
>> /blink
>
>
> _______________________________________________
> Blink mailing list
> Blink at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo/blink