Hi Stephen,
I suspect the 488 is due to the 'o=' line.. Not sure if this is
intentional, but 'o=' line can only have the
format 'o=<username> <session id> <version> <network type> <address
type> <address>', but in ur case 'o=' line 
has other line embedded in itself..

--Arun.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Thursday, February 12, 2009 10:30 PM
To: [email protected]
Subject: Sip-implementors Digest, Vol 71, Issue 26

Send Sip-implementors mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Sip-implementors digest..."


Today's Topics:

   1. 488 Invalid incoming Gateway SDP: Invalid media (Stephan Steiner)
   2. Re: 488 Invalid incoming Gateway SDP:     Invalid media (Dale
Worley)
   3. Re: 488 Invalid incoming Gateway SDP:     Invalidmedia
      (Stephan Steiner)


----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Feb 2009 22:52:49 +0100
From: "Stephan Steiner" <[email protected]>
Subject: [Sip-implementors] 488 Invalid incoming Gateway SDP: Invalid
        media
To: <[email protected]>
Message-ID: <5644ec80b3894475865ab23a47823...@xpc4>
Content-Type: text/plain;       charset="iso-8859-1"

Hi

The 488 response is what I get when I connect our office PBX
(Alcatel-Lucent OmniPCX Enterprise 9.0 - AKA OXE) to Microsoft's Office
Communication Server R2 via SIP and call from the OXE to OCS (the
reverse way works just fine.

I fired up Wireshark and this is what happens between the two systems.

Actors: caller: 3462 (10.145.26.27) on PBX 10.145.27.72 (OXE) Mediation
Server: 10.145.206.156 (that's the server that translates G.711 to
Microsoft's proprietary RTAudio codec)

INVITE sip:[email protected];transport=TCP;user=phone SIP/2.0
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, SUBSCRIBE, OPTIONS,
UPDATE, INFO
Supported: replaces,timer,100rel
User-Agent: OmniPCX Enterprise R9.0 h1.301.25
Session-Expires: 1800;refresher=uac
Min-SE: 900
P-Asserted-Identity: "Tarzis Kessler" <sip:[email protected];user=phone>
Content-Type: application/sdp
To: <sip:[email protected];user=phone>
From: "Tarzis Kessler"
<sip:[email protected]>;tag=a46f56845e2649610af4db5cbb5864ba
Contact: <sip:10.145.27.72;transport=TCP>
Call-ID: [email protected]
CSeq: 1993218136 INVITE
Via: SIP/2.0/TCP
10.145.27.72;branch=z9hG4bK1b582e17fe997251482147f190c49344
Max-Forwards: 70
Content-Length: 316

v=0
o=OXE 1233842864 1233842864 IN IP4 10.145.27.72 s=abs c=IN IP4
10.145.26.27 t=0 0 m=audio 32514 RTP/AVP 8 0 4 97 a=sendrecv
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:30
a=rtpmap:0 PCMU/8000
a=ptime:20
a=maxptime:30
a=rtpmap:4 G723/8000
a=ptime:30
a=maxptime:30
a=rtpmap:97 telephone-event/8000

SIP/2.0 100 Trying
FROM: "Tarzis
Kessler"<sip:[email protected]>;tag=a46f56845e2649610af4db5cbb5864ba
TO: <sip:[email protected];user=phone>
CSEQ: 1993218136 INVITE
CALL-ID: [email protected]
VIA: SIP/2.0/TCP
10.145.27.72;branch=z9hG4bK1b582e17fe997251482147f190c49344
CONTENT-LENGTH: 0

SIP/2.0 488 Invalid incoming Gateway SDP: Invalid media
FROM: "Tarzis
Kessler"<sip:[email protected]>;tag=a46f56845e2649610af4db5cbb5864ba
TO: <sip:[email protected];user=phone>;epid=3CAD90C5CE;tag=43d88de011
CSEQ: 1993218136 INVITE
CALL-ID: [email protected]
VIA: SIP/2.0/TCP
10.145.27.72;branch=z9hG4bK1b582e17fe997251482147f190c49344
CONTENT-LENGTH: 0
SERVER: RTCC/3.5.0.0 MediationServer

Seeing as there is no RTP traffic whatsoever, I figure the Mediation
Server must be objecting to the SDP in the original INVITE. However, at
first glance I don't see anything that's off and the MS support
newgroups are a bust so I'm wondering if somebody here sees something
off in that exchange that could point me towards a solution.

Thanks in advance
Stephan

------------------------------

Message: 2
Date: Wed, 11 Feb 2009 17:09:07 -0500
From: "Dale Worley" <[email protected]>
Subject: Re: [Sip-implementors] 488 Invalid incoming Gateway SDP:
        Invalid media
To: Stephan Steiner <[email protected]>
Cc: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain

On Wed, 2009-02-11 at 22:52 +0100, Stephan Steiner wrote:
> v=0
> o=OXE 1233842864 1233842864 IN IP4 10.145.27.72 s=abs c=IN IP4 
> 10.145.26.27 t=0 0 m=audio 32514 RTP/AVP 8 0 4 97 a=sendrecv
> a=rtpmap:8 PCMA/8000
> a=ptime:20
> a=maxptime:30
> a=rtpmap:0 PCMU/8000
> a=ptime:20
> a=maxptime:30
> a=rtpmap:4 G723/8000
> a=ptime:30
> a=maxptime:30
> a=rtpmap:97 telephone-event/8000

I see that the first m-group has 3 instances of a=ptime and 3 of
a=maxptime, and the ptime values are not consistent.  As far as I know
(and I may be wrong), the a=rtpmap attributes do not create subgroups of
the a-lines within the m-group, so the various a=ptime values contradict
each other, rather than describing separate ptimes for each codec.

Dale




------------------------------

Message: 3
Date: Thu, 12 Feb 2009 14:40:13 +0100
From: "Stephan Steiner" <[email protected]>
Subject: Re: [Sip-implementors] 488 Invalid incoming Gateway SDP:
        Invalidmedia
To: "Dale Worley" <[email protected]>
Cc: [email protected]
Message-ID: <b785cbec26b2464785a51dc78d2e6...@xpc4>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
        reply-type=original

Dale

Is there any guidance in an RFC with regards to that? I dug out an older
thread
(http://www.opensubscriber.com/message/[email protected]/
6832126.html)
where Bala said those attributes are global, not codec specific. Is
there any reference for that (in that case we can open a case with the
manufacturer of the PBX)? For now we're attempting to remove the codec
that causes the inconsistency in the hopes that this will permit
interoperability but of course the end goal is to have it fixed in case
G.723 ever becomes needed.

Regards
Stephan

--------------------------------------------------
From: "Dale Worley" <[email protected]>
Sent: Wednesday, February 11, 2009 11:09 PM
To: "Stephan Steiner" <[email protected]>
Cc: <[email protected]>
Subject: Re: [Sip-implementors] 488 Invalid incoming Gateway SDP: 
Invalidmedia

> On Wed, 2009-02-11 at 22:52 +0100, Stephan Steiner wrote:
>> v=0
>> o=OXE 1233842864 1233842864 IN IP4 10.145.27.72
>> s=abs
>> c=IN IP4 10.145.26.27
>> t=0 0
>> m=audio 32514 RTP/AVP 8 0 4 97
>> a=sendrecv
>> a=rtpmap:8 PCMA/8000
>> a=ptime:20
>> a=maxptime:30
>> a=rtpmap:0 PCMU/8000
>> a=ptime:20
>> a=maxptime:30
>> a=rtpmap:4 G723/8000
>> a=ptime:30
>> a=maxptime:30
>> a=rtpmap:97 telephone-event/8000
>
> I see that the first m-group has 3 instances of a=ptime and 3 of
> a=maxptime, and the ptime values are not consistent.  As far as I know
> (and I may be wrong), the a=rtpmap attributes do not create subgroups
of
> the a-lines within the m-group, so the various a=ptime values
contradict
> each other, rather than describing separate ptimes for each codec.
>
> Dale
>
> 


------------------------------

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

End of Sip-implementors Digest, Vol 71, Issue 26
************************************************

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to