I agree with Dale that SIP was designed in internet way wherein
endpoints has to be intelligent.
But the legacy telecom system believes in the network as intelligent
with full of dump end-points from PSTN days, this leads to the building
of SIP network full of B2BUA/stateful proxy. IMS architectu
I agree with Dale and Brett, sort of.
Brett is right that the UAC is correct in ignoring the change in the
200. Dale is right that the UAS is wrong in sending different SDP in the
180 and 200.
See http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-13.txt
Thanks,
Paul
On
Adding to what brett said...
Why is it necessary to have a separate null address for IPv6?
Null is null. Won't an IPv4 null address do? Even if your node doesn't
support IPv4, I would think it could support a *null* IPv4.
Thanks,
Paul
On 2/7/2011 7:09 AM, Brett Tate wrote:
>> Wh
I would argue for the opposite convention: The URI should contain the real
domain name, since "everything in SIP is encoded in UTF-8". Only at the point
of resolving the domain name into destination addresses (the RFC 3263 process)
would I translate "blåbärsmjölk.se" into "xn--blbrsmjlk-x2aj4s
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Peter Krebs
[pkr...@gmail.com]
I have a short question about the SDP rtpmap attribute (I hope, SDP-specific
questions are also allowed here?
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
bijoy.prak...@wipro.com [bijoy.prak...@wipro.com]
What I want to confirm is that if this behaviour from the 3rd party is
proper that is chan
> <
> 180 Ringing (SDP sent with media port set as )
>
> <
> 200 OK (SDP sent with media port set as )
>
>
> Our SIP implementation does not accept the port change
> and there is no call path b
On 02/10/2011 10:42 AM, Saúl Ibarra Corretgé wrote:
> Hi,
>
> On Thu, Feb 10, 2011 at 1:37 PM, wrote:
>> Hi,
>>
>> I have this specific scenario and would like to know if its proper.
>>
>> We have a SIP Phone connected to our end which calls a third party SIP
>> phone.
>>
>> The scenario is someth
Hi,
On Thu, Feb 10, 2011 at 1:37 PM, wrote:
> Hi,
>
> I have this specific scenario and would like to know if its proper.
>
> We have a SIP Phone connected to our end which calls a third party SIP
> phone.
>
> The scenario is something like this:
>
> Our Phone 3rd Party
>
On 02/10/2011 06:37 AM, bijoy.prak...@wipro.com wrote:
> Hi,
>
> I have this specific scenario and would like to know if its proper.
>
> We have a SIP Phone connected to our end which calls a third party SIP
> phone.
>
> The scenario is something like this:
>
> Our Phone3rd
Hi,
I have this specific scenario and would like to know if its proper.
We have a SIP Phone connected to our end which calls a third party SIP
phone.
The scenario is something like this:
Our Phone3rd Party
->
Hello,
I have a short question about the SDP rtpmap attribute (I hope, SDP-specific
questions are also allowed here?): What characters are allowed in the
encoding name? The BNF in RFC4566 only states that attribute values can take
a "byte-string", but surely this can not be valid for the encoding
10 feb 2011 kl. 09.06 skrev Saúl Ibarra Corretgé:
> Hi,
>
>> Agree. And to clarify a bit more:
>>
>> Important to note is that I think that you should never store the viewing
>> version, like "olle@blåbärsmjölk.se" in infrastructure databases, nor handle
>> it in the protocol messages. The so
> My question is how do i send the path vector in that 302?
> Is there a standardized contact header parameter to do this?
The sip-uri allows embedded headers; headers within a sip-uri are discussed
with rfc3261 section 19.1.1. Thus the Route can be embedded within the
Contact's sip-uri.
__
Hi,
I'm trying to add support for the Path extension to my registrar. The
registrar is providing the soft-switch with location information via a 302
redirect.
My question is how do i send the path vector in that 302? Is there a
standardized contact header parameter to do this?
--
Alex Herma
Hi,
> Agree. And to clarify a bit more:
>
> Important to note is that I think that you should never store the viewing
> version, like "olle@blåbärsmjölk.se" in infrastructure databases, nor handle
> it in the protocol messages. The software that shows URI's to users and
> accept user input will
16 matches
Mail list logo