Thanks,
Not sure about the Contact header. The 2543 document uses
the 1#(name-addr | addr-spec)... syntax which implies that
a contact header can contain at least 1 but optionally multiple
addresses.
Do you remember where you saw the restriction on the number
of contacts that may be in a given method, particularly the invite
method?
If multiple contact headers are present then you would care
only about the ones with a sip or tel uri. Would use one with highest
"qvalue", if q is present. Otherwise, I guess you would use the first
header in the list.
Doug
Christer Holmberg wrote:
> Hi Doug,
>
> Doug Hurtig wrote:
> >
> >Christer,
> >
> >Below you suggest that multiple contacts headers should
> >be allowd in an invite. I have assumed that an invite can
> >already have multiple contact records. Is this not true?
>
> My understanding was that it is not. Maybe this has changed, so I guess
> it's better to verify it :)
>
> >I sent the original message just to find out if it would
> >be a problem when I received a URI as a telephone number,
> >if it would be allowed to send my response with SIP URIs.
>
> First, I don't think that's a good idea. I would be very telephone
> number specific, and it could cause mapping problems somewhere.
>
> Second, I don't see the idea of using tel-urls in the first place :)
> Everything you can do with a tel-url you can do with a sip-url. Or?
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> >
> > If there are multiple contact headers, then I assume that all
> > of them would be copied to the route header.
> >
> >
> > Doug
> >
> >
> > > Hi Jon,
> > >
> > > First a comment on the thread in general.
> > >
> > > It's true that a tel-url can be mapped into a sip-url, but do we really
> > > solve a problem by allowing only sip-url and tel-url in the Contact
> > > header? Sure, this would solve the problem when we talk about telephone
> > > numbers, but isn't the whole idea of what we are doing to finally go
> > > "beyond" that?
> > >
> > > >My original mail on this subject was intended to refer only to UA call
> > > >set-up behavior (the subject that kicked off this thread); bis 2.2
> > > >explicitly forbids non-SIP URIs in the Contact headers of INVITE,
> OPTIONS,
> > > >BYE, and 2xx messages, -not- 3xx messages nor REGISTER. Sorry for my
> lapse
> > > >of precision; didn't mean to start a panic here.
> > >
> > > I think the proposal I wrote in my other mail (by specifying the
> > > supported URI in an Accept-XXX header) would solve also this. In my
> > > initial INVITE I add a Contact with ANY URI, and if the receiver
> doesn't
> > > support it he will send some 4xx response, and a header indicating
> which
> > > URIs he supports. An idea could be to even allow multiple Contacts, all
> > > with different URIs, in the INVITE, and the UAS can choose the one he
> > > wants and/or supports...
> > >
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > Regards,
> > Doug Hurtig
> >
> > Tekelec
> > 2425 N. Central Expressway
> > Richardson, Texas 75080
> >
> > [EMAIL PROTECTED]
> > 972.301.1203
> >
> (See attached file: christer.holmberg.vcf)
--
Regards,
Doug Hurtig
Tekelec
2425 N. Central Expressway
Richardson, Texas 75080
[EMAIL PROTECTED]
972.301.1203
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
