Subject: [p2p-sip] What are we doing, question 2

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 7 Jun 2006 15:42:21 -0700

I encounter a question of SIP on address resolution. It is not about p2psip.
I just need advice and vision into the question because people here are
masters on SIP and firewall penetration.

An UAS receives a request via UDP. Source address in the udp header is
ipx:portx, and sent-by in topmost Via is "ipy:porty", where ipx<>ipy. There
is no empty "rport" parameter in topmost Via of the request.

To which address (ip and port) should the UAS send responses? Why? What for
(ie. practical real-world use)?

Please ignore the message if you won't shed the light.

3q.

Peter
----- Original Message -----
From: "Peter Pan" <huang-ming.pan at comcast.net>
To: "David A. Bryan" <bryan at ethernot.org>
Cc: "Eunsoo Shim" <eunsoo at research.panasonic.com>; "David Barrett"
<dbarrett at quinthar.com>; <p2p-sip at cs.columbia.edu>
Sent: Wednesday, June 07, 2006 11:14 AM
Subject: Re: [p2p-sip] What are we doing, question 2

> 3q for the comfort.
>
> ----- Original Message -----
> From: "David A. Bryan" <bryan at ethernot.org>
> To: "Peter Pan" <huang-ming.pan at comcast.net>
> Cc: "Eunsoo Shim" <eunsoo at research.panasonic.com>; "David Barrett"
> <dbarrett at quinthar.com>; <p2p-sip at cs.columbia.edu>
> Sent: Wednesday, June 07, 2006 10:28 AM
> Subject: Re: [p2p-sip] What are we doing, question 2
>
>
> > At risk of having one David answer on behalf of another ;)
> >
> > My opinion is that we will need to avail ourselves of the ICE-family
> > tools to do NAT traversal since as you point out, we are not likely to
> > have SBCs in the picture. The odds are that using the ICE stuff will
> > be far more critical for P2P systems than CS where things like SBCs
> > can be used as band aids for the problem.
> >
> > As far as features, a few comments. Some I think will work quite
> > transparently with P2PSIP -- transfers of various types, redirects on
> > busy/unavailable, call forward. Some others are likely to be far more
> > challenging -- obviously VM being one -- but features like this aren't
> > always specified in the protocols anyway -- look at SIP where many are
>
> [pp]: Yes or no, imo.
>
> The reasons why sip seemingly cover all scenarios so far without twisting
> itself are, among others:
>
> * There are trucks of "informative" drafts and RFCs to supplement RFC3261;
> these informative specs are helpful but also bring "informative"
> incompatibilities among existing SIP systems or service networks.
> * Usually it is the "feature" servers (like those b2bua based call
managers
> by broadsoft/sylantro/avaya/nortel/...) in c/s softswitch systems that
> bridge the incompleteness of rfc3261 by means of the primitives defined in
> rfc3261 and other RFCs. In p2psip territory, there seems no more such
> "manipulators". The manipulation will likely be done by p2psip nodes
alone.
>
> > not specified directly in the protocol. Forking (so multiple
> > appearance) is another that will be interesting and I can imagine may
> > need to be treated differently in a P2P than CS scenario.
> >
> > In my vision for this, if a feature works as is or can be made to work
> > with essentially no changes, P2P should not reinvent the wheel. Only
> > do that for features that are truly dependent on servers in
> > traditional CS SIP.
> [pp]: Do you have kindly something persuasive other than vision and
promise
> which can ease this long-term concern (backward compitibility of
incremental
> p2psip protocol) of mine, for example, technical paper or open-source
> reference implementation (that has been able to add most well-known call
> features without changing architecture/protocol/implementation too much)?
I
> will really appreciate it since i've been always believing that p2psip is
> not initiated for basic session initiation only.
>
> peter
>
>

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Fri, 9 Jun 2006 21:24:24 -0700

If the Via says port 1000 and you received it from port 2000 and  
there is no rport, the spec says you send back to 1000. (If there was  
an rport, you would send to 2000).

The reason why is some devices send from a different port than they  
receive on - typically they receive on 5060 but send from some  
ephemeral port allocated by OS. If they device sends and receives  
from same port, it needs to indicate this by inserting the rport flag  
in the via.

On Jun 7, 2006, at 3:42 PM, Peter Pan wrote:

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 9 Jun 2006 23:03:56 -0700

Thanks a lot for the comments.

I did some survey of RFC 3261 and 3581 in this regard, and got my preliminary conclusion that the response MUST be sent to address "ipx:porty", which seems unreasonable.

For example, a UAS receives a request via UDP with

  the address in sent-by of Via = 172.2.2.2:6666, with no rport in Via
  the address in udp header = 172.1.1.1:5555

According to Sec 18.2.1 of RFC 3261, UAS MUST add  ";received=172.1.1.1:5555" to the Via.

It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my interop partner insists).

Finally, per Sec 18.2.2 of RFC 3261 (instead of Sec 4 of RFC 3581), UAS MUST send the response to address "172.1.1.1:6666".

But 172.1.1.1:6666 reads like "my ip and his port" or "my body and his head", which to me apparently makes no sense, unless I miss any possible intrigue. 

Please correct me if I misunderstand the RFCs; or, please reveal the intrigue should you know it.

3q and have a nice weekend!!

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060610/69af5828/attachment.html

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Sat, 10 Jun 2006 10:52:10 -0700

On Jun 9, 2006, at 11:03 PM, Peter Pan wrote:

> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily"  
> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my  
> interop partner insists).

I think you interop partner is correct.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Sat, 10 Jun 2006 10:59:18 -0700

> I think you interop partner is correct.

Is my conclusion that the UAS must send response to ipX:portY also correct?
If yes, what could the address ipX:portY possibly mean?

Thanks.

Peter

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Sun, 11 Jun 2006 10:07:32 -0700

> I think you interop partner is correct.

Actually the partner raised the issue via some sort of stress test possibly
for curiosity. Her UAC (likely a robot) cannot resend the request on no
response. There seems nothing practically correct or incorrect.

Unless pointers to convincing explanations about what the responded address
"ipX:portY" may be could kindly show up, personally I will close the case as
an incompleteness of current SIP related RFCs. (Never mind it, for SIP alone
seems never designed to cover all NAT scenarios:)

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Sun, 11 Jun 2006 13:02:33 -0700

> If yes, what could the address ipX:portY possibly mean?

I don't understand what you mean by this.

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Sun, 11 Jun 2006 17:11:42 -0700

I don't think there is anything "incomplete" about this part of the  
spec. I think it is pretty clear how it works and I explained why it  
worked that way in previous email. The way you are proposing (if I  
understand correctly, and I certainly may not) does not work with  
substantial amounts of equipment that sends and receives from  
different ports.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Sun, 11 Jun 2006 20:28:24 -0700

OK, with tx and rx on different ports, let's take the following UAC as a specific example:

It sends msg at private address 192.168.1.1:5060 which is NAT-ed to public addr 209.133.55.1:20006.
It recvs msg  at private address 192.168.1.1:5070 which is NAT-ed to public addr 209.133.55.1:20007.

(Remind you that, in the issue of debate, the ip in Via sent-by is NOT equal to that in UDP header)

Now UAC sends a req via UDP, with

  Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) 
  UDP src addr= 209.133.55.1:20006

According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. 

Does the address 209.133.55.1:5070 make any sense? No, apparently!!

(Neither, if send-by = 192.168.1.1:5060)

You could say that UAC should probe STUN beforehand and set Via sent-by to the public (rx) address 209.133.55.1:20007 and it will work. Yes, but that will NOT be the same problem as the debated one because of precondition in the reminder above, not to mention that RFC 3581 (or rport) would have been completely unnecessary if UA could always consult STUN beforehand to set sent-by to a public address.

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060611/fc3e19e0/attachment.html

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Sun, 11 Jun 2006 20:48:39 -0700

If the device receives SIP on the same ports it sends from, it adds  
an rport and all of this is irrelevant. If it does not send from the  
same port it receives from - nothing you are proposing will work and  
it will break existing devices. The advice is very simple, make you  
device send and receive SIP from same UDP port and add an rport flag  
in the Via - then everything works fine. This does not need STUN to  
work, it works fine with NATs, and it is backwards compatible with  
devices that don't send on same port they receive on.

On Jun 11, 2006, at 8:28 PM, Peter Pan wrote:

> You could say that UAC should probe STUN beforehand and set Via  
> sent-by to the public (rx) address 209.133.55.1:20007 and it will  
> work. Yes, but that will NOT be the same problem as the debated one  
> because of precondition in the reminder above, not to mention that  
> RFC 3581 (or rport) would have been completely unnecessary if UA  
> could always consult STUN beforehand to set sent-by to a public  
> address.
>
> Peter
> > > Unless pointers to convincing explanations about what the  
> responded
> > > address

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060611/eb7bd7f9/attachment.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Sun, 11 Jun 2006 21:10:51 -0700

I'm sorry that you never read carefully the problem raised by my interop partner and my messages so far, especially on the "unequal ip" precondition. If you did, we can save all these back and forth :)

BTW, please see [pp]s inline.

Peter
  ----- Original Message ----- 
  From: Cullen Jennings 
  To: Peter Pan 
  Cc: p2p-sip at cs.columbia.edu 
  Sent: Sunday, June 11, 2006 8:48 PM
  Subject: Re: [p2p-sip] What are we doing, question 2

  If the device receives SIP on the same ports it sends from, it adds an rport and all of this is irrelevant. If it does not send from the same port it receives from - nothing you are proposing will work and it will break existing devices.
  [pp]: No, when rx and tx on different ports and UAC sets sent-by = public rx address (w/o rport), it will work. Just need STUN.

   The advice is very simple, make you device send and receive SIP from same UDP port and add an rport flag in the Via - then everything works fine. 
  [pp]: Didn't you say "substantial amounts of equipment that sends and receives from different ports" below??? I'm worry about those equipments, not mine. 

  My device tx/rx on the same port from day one. I always hate trouble, but my interop partner seems love trouble :-)

  This does not need STUN to work, it works fine with NATs, and it is backwards compatible with devices that don't send on same port they receive on. 

  [pp]: How can RFC 3261/3581 be "backwards compatible" with these substantial amounts of equipments when they are behind NAT without STUN ??? I really doubt it without your further elaborations. Thanks!!

    Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/38ea6fe5/attachment-0001.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Sun, 11 Jun 2006 21:22:45 -0700

Also, I proposed nothing, did I?

I only asked a question raised by my interop partner and requested for
comment or answer to the question as well as for clarification of possible
incompleteness of current RFC regarding the raised question.

Peter
----- Original Message -----
From: Peter Pan
To: Cullen Jennings
Cc: p2p-sip at cs.columbia.edu
Sent: Sunday, June 11, 2006 9:10 PM
Subject: Re: [p2p-sip] What are we doing, question 2

I'm sorry that you never read carefully the problem raised by my interop
partner and my messages so far, especially on the "unequal ip" precondition.
If you did, we can save all these back and forth :)

Peter
----- Original Message -----
From: Cullen Jennings
To: Peter Pan
Cc: p2p-sip at cs.columbia.edu
Sent: Sunday, June 11, 2006 8:48 PM
Subject: Re: [p2p-sip] What are we doing, question 2

If the device receives SIP on the same ports it sends from, it adds an rport
and all of this is irrelevant. If it does not send from the same port it
receives from - nothing you are proposing will work and it will break
existing devices.
[pp]: No, when rx and tx on different ports and UAC sets sent-by = public rx
address (w/o rport), it will work. Just need STUN.

 The advice is very simple, make you device send and receive SIP from same
UDP port and add an rport flag in the Via - then everything works fine.
[pp]: Didn't you say "substantial amounts of equipment that sends and
receives from different ports" below??? I'm worry about those equipments,
not mine.

My device tx/rx on the same port from day one. I always hate trouble, but my
interop partner seems love trouble :-)

This does not need STUN to work, it works fine with NATs, and it is
backwards compatible with devices that don't send on same port they receive
on.

[pp]: How can RFC 3261/3581 be "backwards compatible" with these substantial
amounts of equipments when they are behind NAT without STUN ??? I really
doubt it without your further elaborations. Thanks!!

OK, with tx and rx on different ports, let's take the following UAC as a
specific example:

It sends msg at private address 192.168.1.1:5060 which is NAT-ed to public
addr 209.133.55.1:20006.
It recvs msg  at private address 192.168.1.1:5070 which is NAT-ed to public
addr 209.133.55.1:20007.

(Remind you that, in the issue of debate, the ip in Via sent-by is NOT equal
to that in UDP header)

You could say that UAC should probe STUN beforehand and set Via sent-by to
the public (rx) address 209.133.55.1:20007 and it will work. Yes, but that
will NOT be the same problem as the debated one because of precondition in
the reminder above, not to mention that RFC 3581 (or rport) would have been
completely unnecessary if UA could always consult STUN beforehand to set
sent-by to a public address.

Peter

---

From: stefan_nitschke at hotmail.com (Stefan Nitschke)
Date: Mon, 12 Jun 2006 08:24:23 +0000

Hi Peter,

from my understanding the client has to use:

  Via sent-by = 192.168.1.1:5070;rport

This way it signals to the reciever that it does support symmetric signaling 
and the receiver can use the rport and received parameters to send it 
response to.
A missing "rport" has the meaning of non symmetric signaling.

regards,
Stefan

>To: "Cullen Jennings" <fluffy at cisco.com>
>CC: p2p-sip at cs.columbia.edu
>Date: Sun, 11 Jun 2006 20:28:24 -0700
>

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 08:13:51 -0700

Hi, Stefan.

Thanks for the comment.

Unfortunately, as you could see below, the client below is NOT supporting symmetric signaling; it uses asymmetric signaling. Cullen mentioned below that there are substantial amounts of such equipments that sends and receives from different ports.

Do you or anyone know how RFC 3261/3581 and other SIP RFCs together can be "backwards compatible" with those Cullen-mentioned "substantial amounts of equipments that sends and receives from different ports" when they are behind (any kind of) NAT and without STUN? 

I will appreciate any kindly elaboration.

Thanks.

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/7391f494/attachment-0001.html

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 12 Jun 2006 11:19:04 -0400

This might be a good thread to move to the Columbia SIP implementors
mailing list. That is generally the place with the most experience on
interop/implemenation type questions.

David

On 6/12/06, Peter Pan <huang-ming.pan at comcast.net> wrote:
>
>
> Hi, Stefan.
>
> Thanks for the comment.
>
> Unfortunately, as you could see below, the client below is NOT supporting
> symmetric signaling; it uses asymmetric signaling. Cullen mentioned below
> that there are substantial amounts of such equipments that sends and
> receives from different ports.
>
> Do you or anyone know how RFC 3261/3581 and other SIP RFCs together can be
> "backwards compatible" with those Cullen-mentioned "substantial amounts of
> equipments that sends and receives from different ports" when they are
> behind (any kind of) NAT and without STUN?
>

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 12 Jun 2006 08:36:36 -0700

It seems your primary goal is to claim that something does not work.  
The truth is that it works fine if you follow the RFCs, many vendors  
have implemented it, there are many end points deployed that use  
rport. I don't know what else to say. You are right that if you  
violate the RFCs then it does not work.

On Jun 11, 2006, at 9:10 PM, Peter Pan wrote:

> I'm sorry that you never read carefully the problem raised by my  
> interop partner and my messages so far, especially on the "unequal  
> ip" precondition. If you did, we can save all these back and forth :)
>
> an rport and all of this is irrelevant. If it does not send from  
> the same port it receives from - nothing you are proposing will  
> work and it will break existing devices.
> [pp]: No, when rx and tx on different ports and UAC sets sent-by =  
> public rx address (w/o rport), it will work. Just need STUN.
>
>  The advice is very simple, make you device send and receive SIP  
> from same UDP port and add an rport flag in the Via - then  
> everything works fine.
> [pp]: Didn't you say "substantial amounts of equipment that sends  
> and receives from different ports" below??? I'm worry about  
> thoseequipments, not mine.
>
> My device tx/rx on the same port from day one. I always hate  
> trouble, but my interop partner seems love trouble :-)
> backwards compatible with devices that don't send on same port they  
> receive on.
>
> [pp]: How can RFC 3261/3581 be "backwards compatible" with these  
> substantial amounts of equipments when they are behind NAT without  
> STUN ??? I really doubt it without your further elaborations. Thanks!!
>
>
>> work. Yes, but that will NOT be the same problem as the debated  
>> one because of precondition in the reminder above, not to mention  
>> that RFC 3581 (or rport) would have been completely unnecessary if  
>> UA could always consult STUN beforehand to set sent-by to a public  
>> address.
>>
>> Peter
>> > > Actually the partner raised the issue via some sort of stress  
>> test
>> > > possibly
>> > > an incompleteness of current SIP related RFCs. (Never mind it,  
>> for
>> > > SIP alone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/0ab92a77/attachment-0001.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 08:46:58 -0700

Please prove that it work fine with just a simple example, instead of guessing someone else's goal when his is different from yours. Often answer is biased when anger is in your mind.

By the way, I never said rport does not work; it works and I DO use it. 

What I argue is that nothing in current SIP RFCs seems work with your mentioned "substantial amounts of such equipments that sends and receives from different ports" WITHOUT STUN.

Thanks.

Peter
  ----- Original Message ----- 
  From: Cullen Jennings 
  To: Peter Pan 
  Cc: p2p-sip at cs.columbia.edu 
  Sent: Monday, June 12, 2006 8:36 AM
  Subject: Re: [p2p-sip] What are we doing, question 2

  It seems your primary goal is to claim that something does not work. The truth is that it works fine if you follow the RFCs, many vendors have implemented it, there are many end points deployed that use rport. I don't know what else to say. You are right that if you violate the RFCs then it does not work. 

    Peter
      ----- Original Message -----
      From: Cullen Jennings
      To: Peter Pan
      Cc: p2p-sip at cs.columbia.edu
      Sent: Sunday, June 11, 2006 8:48 PM
      Subject: Re: [p2p-sip] What are we doing, question 2

       The advice is very simple, make you device send and receive SIP from same UDP port and add an rport flag in the Via - then everything works fine.
      [pp]: Didn't you say "substantial amounts of equipment that sends and receives from different ports" below??? I'm worry about thoseequipments, not mine.

        Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/bf4d20c6/attachment-0001.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 08:49:09 -0700

Before moving the thread elsewhere, could anyone send me a simple call
example or trace (copy-n-paste is ok) illustrating how current SIP RFCs are
backward compatible with those substantial amounts of equipments without
STUN? If none, it is ok. I'm going to close the thread anyway since somebody
of distinquish fame seems impatient with me for unknown reason.

Thanks.

Peter
----- Original Message -----
From: "David A. Bryan" <bryan at ethernot.org>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Stefan Nitschke" <stefan_nitschke at hotmail.com>;
<p2p-sip at cs.columbia.edu>
Sent: Monday, June 12, 2006 8:19 AM
Subject: Re: [p2p-sip] What are we doing, question 2

> > > >(Remind you that, in the issue of debate, the ip in Via sent-by is
NOT
> > > >equal to that in UDP header)
> > > >
sent-by
> > to
> > > >will NOT be the same problem as the debated one because of
precondition
> > in
> > > >the reminder above, not to mention that RFC 3581 (or rport) would
have
> > been
test
> > > > > > possibly
> > > > > > for curiosity. Her UAC (likely a robot) cannot resend the
request
> > > > > > on no
responded
for

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 12 Jun 2006 10:27:43 -0700

On Jun 12, 2006, at 8:46 AM, Peter Pan wrote:

> What I argue is that nothing in current SIP RFCs seems work with  
> your mentioned "substantial amounts of such equipments that sends  
> and receives from different ports" WITHOUT STUN.
>

I think our miscommunication here may be over where these devices  
work. UAs that do not do rport will not work when they are behind  
NATs but the stuff that does this was not designed to be deployed  
behind NATs.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 10:35:27 -0700

I see.

But my interop partner insists that:
* his device will NOT use rport
* his device will NOT tx and rx on the same address
* his device MAY or MAY NOT sit behind NAT

I guess that his "device" is kind of B2BUA-based call manager sitting behind
NAT.

Peter

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 12 Jun 2006 15:23:31 -0500

> I guess that his "device" is kind of B2BUA-based call manager  

You appear to have a partner, but no interop. If you were married, I  
would recommend a therapist.

His stuff is broken. It's hard to interop with broken stuff, and I  
believe it can not be achieved in a standard manner in this case. You  
will probably have to do many tricky things to get it to even sort of  
work. While we wish you luck, this doesn't apply to the develop of a  
standard solution, and this isn't the right place to talk about  
tricky hacks for working with broken stuff.

We're far more concerned with hacky tricks for unbreaking our own stuff.

--
Dean

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 12 Jun 2006 13:31:43 -0700

> * his device MAY or MAY NOT sit behind NAT

Your interop partners device will probably not work when it is behind  
a NAT. If you add a rport on to the via that a message came from,  
your device will be in violation of the rport specification, your  
devices will not work with other complaint devices, and most  
importantly, it *still* will not work with your interop partners  
devices because that device is sending from a different port than it  
receives on.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 13:32:25 -0700

Wondering how a decent human being in any SIP working group could judge
other people this way?

Let's do this. If I provide you with the call trace and msgs from my interop
partner under non-disclosure agreement, would you be responsible for your
words and express some apology?

Peter

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 12 Jun 2006 13:32:58 -0700

On Jun 12, 2006, at 1:23 PM, Dean Willis wrote:

> You appear to have a partner, but no interop. If you were married,  
> I would recommend a therapist.

Well that does some it up, I really think we should move this to sip- 
implementors if we want to continue.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 13:44:06 -0700

> a NAT.

this is what i've been looking for since i issued the question. based on
"authoritative" knowledge from sip gurus here, i can turn to the partner and
ask that he should do something on his side to correct the interoperability
problem.

> If you add a rport on to the via that a message came from,

UAS adding rport or not seems not a key point here. the key point is on UAC
side, as you said.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 13:51:04 -0700

> implementors if we want to continue.

well, that does some it up for outside world to see thru people here.

let's close this sub thread !!

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 12 Jun 2006 18:18:30 -0500

I don't believe I understand the words you have done me the honor of  
addressing to me. Would you care to make them more clear?

--
Dean Willis

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 16:34:16 -0700

This sub thread has closed. Please take the "honor" and visit the therapist
you would recommend.

---

From: kyara543 at yahoo.com (K.Yamamoto)
Date: Mon, 12 Jun 2006 17:41:37 -0700 (PDT)

THERAPIST IS USELESS TO YAKUZA WHO OCCUPY TOILET AND CAN NOT POO.

YOU KNOW WHAT RFC MEAN? REQUEST FOR "CONSENT"  

YOU NOT CONSENT? WATCH STING!!
 
 KY

Peter Pan <huang-ming.pan at comcast.net> wrote: 
This sub thread has closed. Please take the "honor" and visit the therapist
you would recommend.

----- Original Message -----
From: "Dean Willis" 
To: "Peter Pan" 
Cc: "Cullen Jennings" ; 

> > From: "Dean Willis" 
> > To: "Peter Pan" 
> > Cc: "Cullen Jennings" ; 

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/52ddab8a/attachment-0001.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 18:07:22 -0700

ORZ...

----- Original Message ----- 
From: K.Yamamoto 
To: Peter Pan ; Dean Willis 
Cc: p2p-sip at cs.columbia.edu 
Sent: Monday, June 12, 2006 5:41 PM
Subject: Re: [p2p-sip] What are we doing, question 2

KY

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 12 Jun 2006 20:15:32 -0500

It is sometimes difficult to ascertain the intent of a communicator  
on a mailing list, but I have I have thought many of your messages on  
the p2p-sip list to be aggressive, disruptive, offensive, and quite  
possibly abusive in tone. This may well not have been your intent,  
and if I misunderstood, I apologize. I tried to lighten the tone a  
bit by applying humor, which you seem to have reacted to in a hostile  
fashion indicating that perhaps I was unclear. If I was unclear, then  
I also apologize for that, and I'd like to apologize to the larger  
community for having aggravated the situation.

If on the other hand your intent is to be offensive, we don't have to  
put up with it. I would like to remind you that that the IETF  
community does have a variety of procedures for dealing with  
disruptive individuals. The foremost of these is to simply ignore the  
disruptive individual, but the formal procedures do allow for the  
removal of posting rights and the application of even more stringent  
sanctions. I certainly hope things can be worked out without having  
to resort to those sorts of measures.

Thank you for your consideration. That said, I'd like to ask the list  
participants to honor your wishes and leave the thread closed, and  
let's all get back to work at coming up with a few more agreeable  
points of consensus.

--
Dean Willis

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 18:31:41 -0700

> to resort to those sorts of measures.

Please review all my messages on this thread. If you could find anything as
offensive as your msg that would recommend a therapist which you claim it a
"humor" now, I would apologize the same times as you do.

If you could not, please take my prior msg as my application of humor.

Really ORZ...

Peter