Subject: [dispatch] draft-hanes-dispatch-fax-capability-00

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 15 Aug 2012 05:20:04 -0500

As I previously mentioned on this list
(http://www.ietf.org/mail-archive/web/dispatch/current/msg04238.html), 
the SIP Forum's FAX over IP working group, in conjunction with others in 
the FoIP community, have concluded that the ability to select SIP 
endpoints for session termination based on the need for FAX support by 
the calling endpoint would be quite useful.

As a result, this draft is intended to register a SIP feature tag, for 
use in RFC3840/3841 processing by SIP network elements. This replaces 
the previously discussed 'user=fax' concept, and provides more 
flexibility, while also fitting within the guidelines established by 
published RFCs.

Comments welcome. This is an individual submission and as such doesn't 
require that a WG take the document as its own (and I'm not sure there 
are any existing WGs where it would fit anyway), but of course the 
DISPATCH community can choose to proceed with this document in any way 
that seems suitable :-)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Aug 2012 12:09:07 -0400

Kevin, Hannes,

The concept here seems reasonable to me. But for realization, are you 
aware of RFC 5688, which defined feature tag sip.app-subtype?

So, instead of

	Contact: <sip:[email-masked];transport=tcp;
          ;+sip.fax

one can use:

	Contact: <sip:[email-masked];transport=tcp>
          ;+sip.app-subtype="t38"

I suppose this doesn't cover cases where fax is done some way other than 
t38. But that could be a good thing.

	Thanks,
	Paul

On 8/15/12 6:20 AM, Kevin P. Fleming wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: David Hanes <[email-masked]>
Date: Fri, 17 Aug 2012 21:43:06 -0400

Paul,

Our reservation with the 5688 approach is the narrowing of fax to a T.38 application subtype. Obviously, there are more fax transport methods than just T.38 and it seems like a cleaner approach to add a 3840 base-tag of fax to be on equal footing with already existing base-tags:

  base-tags        =  "audio" / "automata" /
                      "class" / "duplex" / "data" /
                      "control" / "mobility" / "description" /
                      "events" / "priority" / "methods" /
                      "schemes" / "application" / "video" /
                      "language" / "type" / "isfocus" /
                      "actor" / "text" / "extensions"

Adding a tag for fax seems to be a reasonable extension of the base tags that are already defined. Our thinking is that fax should be treated as a different type of session where it can stand on its own, not as an "application" on an existing session type.

Thanks,
David

On Aug 15, 2012, at 12:09 PM, Paul Kyzivat wrote:

> Kevin, Hannes,
> 
> The concept here seems reasonable to me. But for realization, are you aware of RFC 5688, which defined feature tag sip.app-subtype?
> 
> So, instead of
> 
> I suppose this doesn't cover cases where fax is done some way other than t38. But that could be a good thing.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Aug 2012 00:32:29 -0400

> Adding a tag for fax seems to be a reasonable extension of the base tags that are already defined. Our thinking is that fax should be treated as a different type of session where it can stand on it…

I'm just asking, since doing nothing is easier than doing something. :-)

Is it helpful to get a device that does fax but doesn't support the 
*way* of doing fax that you support?

Or are you assuming that all fax devices will support all the different 
fax transport methods? If so, then selecting for T38 should still get 
the desired effect.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Sat, 18 Aug 2012 06:14:40 -0500

On 08/17/2012 11:32 PM, Paul Kyzivat wrote:
>> Our reservation with the 5688 approach is the narrowing of fax to a
>> T.38 application subtype. Obviously, there are more fax transport
>> methods than just T.38 and it seems like a cleaner approach to add a
>> 3840 base-tag of fax to be on equal footing with already existing
>> base-tags:
>>
>> Adding a tag for fax seems to be a reasonable extension of the base
>> tags that are already defined. Our thinking is that fax should be
>> treated as a different type of session where it can stand on its own,
>> not as an "application" on an existing session type.
>

This can be handled by capability negotiation, or even simple 488 
responses to attempts to use a non-supported FAX transport mode.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Aug 2012 15:36:22 +0200

Hi,

Assuming we define a sip.fax feature tag, couldn't it have a value which lists the different supported fax modes.

e.g. +sip.fax="t38, whatever_fax"

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Kevin P. Fleming [[email-masked]]
Sent: Saturday, August 18, 2012 2:14 PM
To: [email-masked]
Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-00

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Sat, 18 Aug 2012 08:50:52 -0500

> e.g. +sip.fax="t38, whatever_fax"

That certainly seems reasonable.

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 18 Aug 2012 13:16:33 -0400

+1 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kevin P. Fleming
Sent: Saturday, August 18, 2012 9:51 AM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-00

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sat, 18 Aug 2012 14:05:00 -0400

> That certainly seems reasonable.

I agree and I think a sufficiently complete list is +sip.fax="t38, passthrough"

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Aug 2012 15:38:11 -0400

> e.g. +sip.fax="t38, whatever_fax"

That might work out.

Can somebody enumerate the alternative forms of fax that should be covered?

	Thanks,
	Paul

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sat, 18 Aug 2012 17:22:41 -0400

> Can somebody enumerate the alternative forms of fax that should be covered?

I think a sufficiently complete list is +sip.fax="t38, passthrough"

--G

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 22 Aug 2012 16:37:07 -0400

> I think a sufficiently complete list is +sip.fax="t38, passthrough"

What is "passthrough"?  I've never heard of SIP fax done by any means
other than T.38.

(Do we intend to allow people to put spaces in the value?)

Dale

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 22 Aug 2012 20:39:11 +0000

>What is "passthrough"?  I've never heard of SIP fax done by any means

Essentially it is fax over a G.711 codec

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 22:47:44 +0200

Hi,

> Essentially it is fax over a G.711 codec

Maybe we should call it "g711", then :)

...unless, of course, there are also other codecs that support fax transport.

Regards,

Christer

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 22 Aug 2012 16:56:13 -0400

> Maybe we should call it "g711", then :)

The term passthrough is commonly used in FoIP circles but I am OK with whatever terminology the group suggests.

Gonzalo

---

From: David Hanes <[email-masked]>
Date: Wed, 22 Aug 2012 17:18:51 -0400

> The term passthrough is commonly used in FoIP circles but I am OK with whatever terminology the group suggests.

Agreed. Passthrough is probably the most common term in FoIP circles. Another option is the term VBD or voice band data. This would align us with other standards bodies such as ITU-T and their V.152 specification. Personally, I think g711, passthrough, or vbd could each work but I am willing to go along with whatever the group feels is appropriate. 

-David

---

From: David Hanes <[email-masked]>
Date: Fri, 31 Aug 2012 22:15:51 -0400

Thanks for the constructive feedback on this draft. I posted a new version of the draft for your review.

 The principal changes in this new version are:

- Per Dan Wing, insertion of a paragraph expanding upon why SDP alone is not suitable for indicating fax capability.

- Per Christer Holmberg, the +sip.fax tag has been changed from a boolean type to token with an equality relationship so that we can now explicitly define the fax transport being used

- addressing various nits and formatting issues

Additional feedback and suggestions on taking this draft forward are welcomed and appreciated.

Regards,
David