oh, duh. The Linksys device is the victim here, not the culprit.
Paul
Paul Kyzivat wrote:
>
> Stephan Steiner wrote:
>> Actually this proxy/registrar (the Linksys SPA9000), does things in a rather
>> interesting way:
>
> Well... you will note that my email address is @cisco.com, and Li
Stephan Steiner wrote:
> Actually this proxy/registrar (the Linksys SPA9000), does things in a rather
> interesting way:
Well... you will note that my email address is @cisco.com, and Linksys
is part of Cisco, but I disclaim any knowledge or responsibility for
what Linksys products do.
More
Actually this proxy/registrar (the Linksys SPA9000), does things in a rather
interesting way:
Here's how the UA registers:
REGISTER sip:192.168.1.4:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.143:1027;branch=z9hG4bK-15jt0sfyr8xy;rport
From: "Stephan Snom" ;tag=hw631v8q8o
To: "Stephan Snom"
Call-ID:
I largely agree with Jeroen.
The UA is the master of its own address. It tells others the address(es)
where it is willing and able to receive requests. REGISTER is one way it
can tell others (the registrar) its address(es).
This is much like postal addresses. A postal address might be:
Hi,
It's implicit. A proxy is expected to consult a location service, and
rewrite the request URI with the result. That result should normally match a
Contact URI which the UAS used in a REGISTER. See section 16.6 point 2.
The description of supporting "broken proxies" is not very helpful. They
Hi
I recently got a new phone that wouldn't accept any calls on my PBX, until a
found an option to support "broken proxies". According to the manufacturer,
this option removes the request URI check, so that the Contact Field in the
REGISTER request won't have to match the Request URI in an inco
It depends on whether you sent that un-acknowledged offer or if this
is the second
outstanding offer you received from the other side.
In the first case, it's glare, and the spec talks about resolving it
(search for the 491 response).
In the second case, the far side is violating spec, and it
On 7/20/07, Anshuman S. Rawat <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I have a setup where UA-A calls UA-B. The call setup faces the problem that
> UA-B never sees the ACK sent by UA-A.
>
> Ethereal snapshot of the INVITE-200OK-ACK seen at UA-A is pasted here for
> reference.
>
>
> >From my unde
Hi,
Assume we receive a new offer, while there is an un-acknowledged offer
in progress, what shud we do with that?
A)Queue it and process later.
B)Return error.
C)Don't respond.
Thanks in advance for your help
Fritz.
-Original Message-
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Se
Based on the Trace caller is using a public IP and the calee a private
IP. And also from the calee UA's Record-route is inserted with a
domain-name in 200 Ok.
ACK has the route header picked from the Record-Route Header of the 200
OK.
Check whether the Proxy which inserted the Record-Route in
Robert,
I hadn't gotten around to looking enough to answer your query. Meanwhile
Michael seems to have done it for me. (Thanks Michael.)
Paul
Michael Procter wrote:
> An extract from RFC3262 might prove helpful here. Section 3, 19th para
> (last paragraph on page 5):
>
> The UAS
Hi All,
I have a setup where UA-A calls UA-B. The call setup faces the problem that
UA-B never sees the ACK sent by UA-A.
Ethereal snapshot of the INVITE-200OK-ACK seen at UA-A is pasted here for
reference.
---
An extract from RFC3262 might prove helpful here. Section 3, 19th para
(last paragraph on page 5):
The UAS MAY send a final response to the initial request before
having received PRACKs for all unacknowledged reliable
provisional
responses, unless the final response in 2xx
13 matches
Mail list logo
