Simon Morlat ha scritto:
> Hi Dave,
> Thanks for the detailed analysis.
> My apologize, indeed the INVITE without SDP is something supported but not the
> RE-INVITE without SDP.
> This is a feature which is lacking in linphone.
> As it is lacking to few people it has never been developped.
> Would you be interested in sending a patch for this ?
> Le vendredi 17 juillet 2009 17:38:25, Dave Harley a écrit :
>> Hi Simon,
>> I managed to get a test preformed using the latest version of Linphone
>> for windows (3.1.2).
>> Hopefully this is up to date enough.
>> 1st test.
>> 1) Linphone calls an analogue extension which is connected to a Mitel
>> 2) Call is established.
>> 3) Analogue extension tries to go on hold.
>> 4) Analogue extension tries to retrieve call from hold.
>> 5) Call is terminated ( actually not sure which end hangs up but its not
>> 2nd test is the exact same with the exception that the call is made from
>> a xlite client.
>> Attached are wireshark pcap traces of the sip transfer for each test and
>> the debug trace produced by the Linphone client.
>> In the Linphone test the interesting bit is that Linphone issue's a 603
>> decline to the bodyless (re-)invite which is received after the dialog
>> has been established.
>> In the 2nd test the xlite response to the same packet is 200 Ok with an
>> SDP body attached, which is acked with an SDP body ( including the hold
>> indication) by the Mitel.
>> The other interesting thing is that the Linphone test shows no
>> indication of a off hold event, which makes sense cause it never went on
>> hold in the first place I guess.
>> The xlite does see the off hold (re-)invite. However in this case the
>> invite does have a body. Screwy pabx!
>> >From my reading of 3216 sec 14.1 I would think that xlite is more
>> compliant, but I suppose I would say that. Certainly from an interop
>> point of view it would be nice if Linphone handled the interaction
>> I'm sure like all RFC's its open to interpretation and the xlite/Mitel
>> interpretation might not match your own views.
>> I'd be grateful if you could let me know your analysis. If there is any
>> further testing I can do let me know and I'll do by best.
>> Best regards,
>> The results are as follows:
>> On Thu, 2009-07-16 at 17:25 +0200, Simon Morlat wrote:
>>> Hi Dave,
>>> Receiving of INVITEs and reINVITEs without SDP is implemented and it
>>> should work. I think it has been implemented shortly after the email you
>>> refer. Try lastest release (3.1.2). This feature is not tested very
>>> often, just tell me if you find a bug.
>>> Le jeudi 16 juillet 2009 16:17:32, Dave Harley a écrit :
>>>> Hi All,
>>>> There was a query about 2 years ago regarding receiving invites and
>>>> re-invites with no sdp offer when interoping with a mitel. It
>>>> referenced 14.1 and 13.2.1 of RFC 3261.
>>>> I'm running an old release of linphone which was happily doing its job
>>>> up to now. However recently it appears that I need to support the
>>>> above against both a Mitel and an Aastra A5000 iPBX.
>>>> At the time Simon pointed out he had no immediate intention of
>>>> implementing this (from the original thread:
>>>> http://www.mail-archive.com/address@hidden/msg01282.html ).
>>>> Just wondering has this situation changed? Is there any support in the
>>>> top of the tree for this aspect of the RFC?
>>>> I would test this myself before asking but getting access to the
>>>> environment where it exhibits is... problematic.
>>>> BTW I originally thought this was an osip issue and posted there. I was
>>>> wrong and was, very helpfully, pointed in the right direction. So
>>>> apologies if this mail seems familiar to any list members.
>>>> Best regards,
>> Dave Harley.Senior Systems Engineer
>> Email: address@hidden Web: www.lincor.com
>> Tel: +353 21 4941607 Fax: +353 21 4800848
>> Integrated Point-Of-Care Entertainment & Information System
>> Unit 6 (Nualight Building), Cork Technology Park, Model Farm Road, Cork,
>> Dublin office : Digital Depot,Thomas Street, Dublin 8, Ireland
>> This email may contain information which is confidential and/or privileged.
>> The information is intended solely for the use of the individual or entity
>> named above. If you are not the intended recipient, be aware that any
>> disclosure, copying, distribution or use of the contents is prohibited. If
>> you have received this electronic transmission in error, please notify the
>> sender by telephone or return email and delete the material from your
> Linphone-developers mailing list
Hi Simon and Dave,
I wrote a patch against linphone 2.1.1 to handle these cases one year
ago. Unfortunately now I have no time to update it to newer linphone.
Maybe that patch can't be applied as is but I hope it can help you.
Linphone-developers mailing list