[Blink] Digest user

Malcolm Caldwell Malcolm.Caldwell at cdu.edu.au
Fri Apr 30 15:06:41 CEST 2010


Hi,

Doing some more digging, shouldn't this type of INVITE be fixed already?

http://trac.pjsip.org/repos/ticket/339

http://osdir.com/ml/voip.pjsip/2007-06/msg00194.html



Malcolm Caldwell

On 30/04/2010, at 18:04, "Adrian Georgescu" <ag at ag-projects.com> wrote:

> 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
>
> _______________________________________________
> Blink mailing list
> Blink at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo/blink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/blink/attachments/20100430/002512bd/attachment.html>


More information about the Blink mailing list