Subject: [Megaco] Megaco, SCTP and IP addresses

From: "Claudio Fontana" <[email-masked]>
Date: Sun, 3 Jun 2007 22:02:38 +0200

Hello all,

I am monitoring some megaco [ver 1, BER, IPv4/SCTP/M3UA] traffic, and
I see something
that should _not_ be ok if I read the involved standards correctly.

I see the equivalent (data changed, but meaning preserved) of these two messages
on the wire, delta_t=3 milliseconds.
No ServiceChange or Notify between the two.

[message 1, Transaction REQUEST, tid=0x155d3327 ctxid=CHOOSE]
mid: 10.5.100.22/2945 ADD REQUEST
ip/sctp src: 10.5.100.22/2945 dest: 10.5.100.1/8009

[message 2, Transaction REPLY, tid=0x155d3327 ctxid = 0x0220c197]
mid: 10.5.100.1/8009 ADD REPLY
ip/sctp src:10.5.101.1/8009 dest: 10.5.101.22/2945

Now, H.248.4 says in the overview that for SCTP
"Responses must be sent to the address and port from which the
corresponding commands were sent, except if the response is to a
handoff or failover,
in which case the procedures of 11.5/H.248.1 apply."

This is not the case with the traffic I am seeing here.
Is there some exception I should know of, or is this simply wrong?

Thank you for your kind advice,

Claudio Fontana

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: [email-masked]
Date: Mon, 11 Jun 2007 16:58:21 +0200

If such an H.248 Control Association is working, then I would agree that
this configuration of the SCTP association is not compliant against
H.248.4.

But I'm hesitate to interprete that H.248.4 statement in that direction
(due to the H.248 Control Association changeover statements in this
sentence; it's also strange to put normative statements into the overview
section).

I may imagine that the developers of H.248.4 had the H.248 Control
Association changeover topic in mind, and perhaps simply overlooked that
the SCTP endpoint could be realized by multi-homed or single-homed "IP
hosts". The IP multihoming approach is leading to different IP interfaces
for ingress and egress traffic, thus different IP addresses (= asymmetrical
IP addresses).
This should be still possible for H.248-over-SCTP.

Please note that IP multihoming is different to the SCTP multihoming
capability. SCTP multiphoming means the support of multiple IP interfaces
(one IP interface per SCTP path).

Anyway, I think that current H.248.4 text make sense (due to the topic of
data localization in a distributed endpoint), but I may also agree that
this statement might be too restrictive for IP multihomed  implementations.

-Albrecht

                      "Claudio                                                                                                       
                      Fontana"                 To:      [email-masked]                                                              
                      <claudio.fontana         cc:                                                                                   
                      @gmail.com>              Subject: [Megaco] Megaco, SCTP and IP addresses                                       
                                                                                                                                     
                      03.06.2007 22:02                                                                                               

Hello all,

I see the equivalent (data changed, but meaning preserved) of these two
messages
on the wire, delta_t=3 milliseconds.
No ServiceChange or Notify between the two.

Claudio Fontana

---

From: "Claudio Fontana" <[email-masked]>
Date: Mon, 11 Jun 2007 19:19:08 +0200

Hello,

thank you for your answer.

> sentence; it's also strange to put normative statements into the overview

If the overview is not normative, maybe I should just ignore it completely
since it just confuses me.

full text is available from ITU-T in pdf format at
http://www.itu.int/rec/T-REC-H.248.4/en

> hosts".

If so, this is a pretty bad overlooking though.
I'd ask them (ITU-T I think) about it, but their mailing lists are not open
for non-TIES members.

> The IP multihoming approach is leading to different IP interfaces

Yes.

> this statement might be too restrictive for IP multihomed  implementations.

I am not sure I understand you here, or how current H.248.4.1 can still make
sense.
You mean that it would be good for associating values unique to a logical megaco
entity, but it is not done in practice?

Thank you very much for your help,

Claudio

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Jun 2007 12:25:11 +1000

Hello Claudio,

With regards to asking the ITU-T about H.248 you don't need to be on 
their lists because there's no ITU-T H.248 list. H.248 issues are 
discussed on this IETF Megaco list.

On the IP Multihoming issue: H.248 Annex H (now H.248.4) was originally 
defined back in 11/2000 when H.248 and SCTP (the RFC was only a month 
old) were relatively new beasts and the authors didn't have 6 years 
implementation experience. Perhaps the authors were focussing on RFC2960 
section 6.4,?which in part says: 

   /"//An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
   etc.) to the same destination transport address from which it
   received the DATA or control chunk to which it is replying.  This
   rule should also be followed if the endpoint is bundling DATA chunks
   together with the reply chunk."/

Given that the H.248 model is command / response perhaps the overview is 
following this guidance?

Regards, Christian