Option 1 might seem OK but the answerer might try to send
to the offerer's first codec, whatever the answerer said.
e.g. Offer 0 3 8
Answer 3 8 0
The offerer could transmit GSM ("3") like you suggested but
the answerer might still transmit PCMU ("0").
So, to get around RFC3264 non-compliance:
1. the offerer should try to transmit using the first codec in the answer.
2. then look at the received RTP headers (as Franz Edler said). If
the offerer receives packets different to that which
it is transmitting, then switch over.
These workarounds may be suitable for now until everyone adheres
to RFC3264.
> -----Original Message-----
> From: Alex Zeffertt [mailto:[EMAIL PROTECTED]
> Sent: 17 September 2003 11:58
> To: Attila Sipos; SIP-LIST
> Subject: RE: [Sip-implementors] which codec will peer send?
>
>
> Attila,
>
> I think I have 2 options:
>
> i) just assume that the first codec listed in the 200 OK
> message is the
> one to use. Most of the time it will be the earliest codec in the
> INVITE to appear in the 200 OK, so both sides agree on prioritisation
> and there's no reason either side would want to use any other
> codec. If
> the invited party reorders the codecs in its 200 OK message, then it's
> breaking an RFC3264 RECOMMENDation, and probably would only
> do so if it
> has a good reason for wanting to use the codec it lists first - so its
> fair to assume that the invited party will actually use that codec.
>
> ii) Implement section 10.2 of RFC3624. (I've just been
> pointed to this
> by someone on the list.) Here you mark the RTP stream as
> "inactive" in
> the initial INVITE, and when you get the 200 OK you can
> re-invite, this
> time listing only one codec and marking the RTP stream as "sendrecv".
> This would be the more standards conformant way of doing it, but it's
> more work, and there's the risk that UAs won't have implemented this -
> less frequently used - bit of the standard.
>
> Anyway, thanks everyone for your help.
>
> Alex
>
>
> On Wed, 2003-09-17 at 11:40, Attila Sipos wrote:
> > No I don't think the Asterisk is the only one.
> > Someone mailed to SIP-implementors last week mentioning
> > an "X-PRO" which also didn't fully comply to RFC3264.
> >
> > I don't know how you can find out a list on
> > non-compliance - I doubt there is one.
> >
> > Good luck!!
> >
> > Attila
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Alex Zeffertt [mailto:[EMAIL PROTECTED]
> > > Sent: 17 September 2003 11:33
> > > To: Attila Sipos
> > > Cc: SIP-LIST
> > > Subject: RE: [Sip-implementors] which codec will peer send?
> > >
> > >
> > > Attila,
> > >
> > > Me again. I've just tested this RECOMMENDation against a
> > > couple of SIP
> > > UAs. linphone adheres to it, but - unfortunately -
> Asterisk PBX does
> > > not.
> > >
> > > I wonder if there is any way to find out if Asterisk is a one
> > > off, or if
> > > there are other UAs that don't adhere to the
> RECOMMENDation as well.
> > >
> > > Alex
> > >
> > > On Wed, 2003-09-17 at 11:21, Attila Sipos wrote:
> > > > No, there is no way to make the answerer select just one.
> > > >
> > > > However, I don't think this is an issue becaause this paragraph
> > > > in RFC3264 is adhered to:
> > > >
> > > > Although the answerer MAY list the formats in their
> > > desired order of
> > > > preference, it is RECOMMENDED that unless there is a
> > > specific reason,
> > > > the answerer list formats in the same relative order
> they were
> > > > present in the offer. In other words, if a stream in
> > > the offer lists
> > > > audio codecs 8, 22 and 48, in that order, and the
> answerer only
> > > > supports codecs 8 and 48, it is RECOMMENDED that, if the
> > > answerer has
> > > > no reason to change it, the ordering of codecs in the
> > > answer be 8,
> > > > 48, and not 48, 8. This helps assure that the same
> > > codec is used in
> > > > both directions.
> > > >
> > > >
> > > > So, I think you will be OK and both will select to use PCMU.
> > > >
> > > > Of course, if the answerer couldn't do PCMU then it
> would answer:
> > > > > > > v=0
> > > > > > > o=vssip 123456 654321 IN IP4 10.0.0.107
> > > > > > > s=A conversation
> > > > > > > c=IN IP4 10.0.0.107
> > > > > > > t=0 0
> > > > > > > m=audio 7078 RTP/AVP 3 8 101
> > > > > > > a=rtpmap:3 GSM/8000/1
> > > > > > > a=rtpmap:8 PCMA/8000/1
> > > > > > > a=rtpmap:101 telephone-event/8000
> > > > > > > a=fmtp:101 0-11
> > > >
> > > > This answer keeps the media formats in the same order
> > > > as the offer. Both ends would transmit GSM.
> > > >
> > > > Regards,
> > > >
> > > > Attila
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Alex Zeffertt [mailto:[EMAIL PROTECTED]
> > > > > Sent: 17 September 2003 11:12
> > > > > To: Attila Sipos
> > > > > Cc: SIP-LIST
> > > > > Subject: RE: [Sip-implementors] which codec will peer send?
> > > > >
> > > > >
> > > > > Attilla,
> > > > >
> > > > > Thanks for your reply. It makes sense to only put one codec
> > > > > in the 200
> > > > > OK message, since you already know what the other end
> > > > > supports. But if
> > > > > I restrict myself to putting only one codec in the INVITE
> > > > > message, then
> > > > > there's a big chance the other end won't support it.
> > > > >
> > > > > Ideally, what I want is to be able to advertise ALL the
> > > > > codecs I support
> > > > > in my INVITE, and somehow force the other end to respond
> > > with just one
> > > > > codec. Is this possible?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Alex
> > > > >
> > > > > On Wed, 2003-09-17 at 10:53, Attila Sipos wrote:
> > > > > > In the SDP response, one should only list multiple
> > > > > > formats if you can support dynamic switching between them.
> > > > > > I get this from top of page 22 RFC3264.
> > > > > > > Bob can support dynamic switching between PCMU and
> > > > > G.723. So, he
> > > > > > > sends the following answer:
> > > > > > Can the second UA really support dynamic switching
> > > between all its
> > > > > > listed media formats? If so, it doesn't matter what
> > > you transmit
> > > > > > to the second UA.
> > > > > >
> > > > > >
> > > > > > I'm guessing but it is likely that, since both
> lists have PCMU
> > > > > > first (payload 0), then PCMU will be chosen.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Alex Zeffertt [mailto:[EMAIL PROTECTED]
> > > > > > > Sent: 17 September 2003 10:46
> > > > > > > To: SIP-LIST
> > > > > > > Subject: [Sip-implementors] which codec will peer send?
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I have a SIP UA implementation which seems to choose the
> > > > > codec to use
> > > > > > > for rx and tx at the point at which the INVITE is
> > > accepted. This
> > > > > > > confuses me because the SDP offer and response contain
> > > > > > > multiple codecs,
> > > > > > > and I can't see how the UA knows which one the other end
> > > > > will start
> > > > > > > sending!
> > > > > > >
> > > > > > > Can anybody explain this to me?
> > > > > > >
> > > > > > > Here's the detail:
> > > > > > >
> > > > > > > The first SIP UA sends the second the following SDP
> > > offer in a SIP
> > > > > > > INVITE:
> > > > > > >
> > > > > > > v=0
> > > > > > > o=vssip 123456 654321 IN IP4 10.0.0.228
> > > > > > > s=A conversation
> > > > > > > c=IN IP4 10.0.0.228
> > > > > > > t=0 0
> > > > > > > m=audio 7078 RTP/AVP 0 3 8 101
> > > > > > > a=rtpmap:0 PCMU/8000/1
> > > > > > > a=rtpmap:3 GSM/8000/1
> > > > > > > a=rtpmap:8 PCMA/8000/1
> > > > > > > a=rtpmap:101 telephone-event/8000
> > > > > > > a=fmtp:101 0-11
> > > > > > >
> > > > > > > Then the second sends the first the following SDP
> > > > > response in it's SIP
> > > > > > > 200 OK message:
> > > > > > >
> > > > > > > v=0
> > > > > > > o=vssip 123456 654321 IN IP4 10.0.0.107
> > > > > > > s=A conversation
> > > > > > > c=IN IP4 10.0.0.107
> > > > > > > t=0 0
> > > > > > > m=audio 7078 RTP/AVP 0 3 8 101
> > > > > > > a=rtpmap:0 PCMU/8000/1
> > > > > > > a=rtpmap:3 GSM/8000/1
> > > > > > > a=rtpmap:8 PCMA/8000/1
> > > > > > > a=rtpmap:101 telephone-event/8000
> > > > > > > a=fmtp:101 0-11
> > > > > > >
> > > > > > > So both know that they both support ulaw (0), gsm
> (3), and
> > > > > > > alaw(8). But
> > > > > > > how do they know which codec the other UA will
> start sending?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Alex
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Sip-implementors mailing list
> > > > > > > [EMAIL PROTECTED]
> > > > > > >
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > > > > > >
> > > > >
> > >
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
